I have a website, which was infected 4 years ago (!) by virus, which created many threads and fake users in ASP.NET Community like : /forum/members/Better-Flower-Delivery-Your-Flower-Delivery-c-uj.aspx .
This site is redesigned 2 years ago, ASP.NET Community is removed at all, but right now there are many requests are being went to my web-site (300 such fake requests per 2 hours)!
Of course requestor (robot) gets HTTP 404, but sends and sends such requests. Any ability to block these requests at all? Why do I want to do it?
I use Azure. So, I pay about each incoming data / CPU time to processing request.
these requests add litter to statistic, so, I should check what is it.
You can try to do something like this:
OnBeginRequest event, send to user a fake page with only one html form that contains some special generated number or string for this user inside hidden field and after page is loaded automatically send this form back to your server by js.
On your server, check this generated number, and if it's valid for this user, generate cookie that informs your system, that this is true user and has a browser.
So if user has your generated cookie with your generated pass, you are allow your server to process this request, if not, reject it.
This method allows you to control which request should be processed by your system, 'cause usually robots don't process responses.
Best regards, Dima.
Related
Excuse me for my poor english.
It's possible get all thread requests from an ASP.NET application?
I don't need execute the complete logout of current user if in same time another clients are authenticated with this same username. Perhaps I could query another request threads for know if I need do that.
I will try simplify the question... Can I know all actives requests from ASP.NET application in a IIS server on C# code?
Now I try get the threads of WebDev.WebServer40.EXE process, but don't seems the requests threads.
I think you are approaching this wrong. You cannot log out a user in the middle of a session since http is stateless and the users credentials are always sent as part of the request, be it a cookie, a Bearer token or some value in the Authorization header.
Performing a logout as part of a single request is therefore not really feasible.
To me it sounds like you want to unauthorize the user without necessarily unauthenticating the user. That is, the user id is still connected to the request, but you no longer want to grant the user access to whatever resource, that was available to the user a moment ago.
This decision is made at a unique point in time, so all requests concurrently with the time you made the decision that the user is now unauthorized will behave differently depending on whether the authorization was checked before or after the unauthorization. New requests are sure to be denied though.
A http request should not take longer than milli seconds or sometimes seconds. Are any ressource you are protecting so important that it cannot live with this inconsistency window, you probably shouldn't expose it via http.
But if you want to make this rather (and perhaps unnecessarily) complex mechanism to unauthorize already authorized request, you should make it as a http handler executing as the last part of the aspx pipeline. It should look at the user id and some kind of shared blacklist maintained by the authorization system.
I think you should live with the inconsistency though. But be sure to separate authentication (who) from authorization (what the user can do).
I did look different possibilities. The best option perhaps is use the System.Web.Administration dll and WorkerProcess.GetRequests method. The main problem is that dll only works with IIS7 version o superiors. Exists some way for get something similar in IIS6? For me the most important is get the current request theads managed by server and know the credentials of each thread and internal info.
Say I have three endpoints
First/foo/bar
Second/fizz/buzz
Third/whatever
Only one of these endpoints is valid at a time, starting with first, then second, and so on. This is a problem is the user tries to go back, or they pick one of these endpoints from their history -- they'll be presented with an error dialog.
I thought I could use SessionState to keep track of the most recently accessed (and thus valid) endpoint and redirect with action filters based on that information, but my team has disabled SessionState.
So does MVC have a canonical way to ensure a user navigates certain endpoints in order?
MVC doesn't provide any behavior over what a browser does. That is, it is using the HTTP protocol and there is no way to prevent a user from manually typing in a URL in their browser (unless you have written your own browser that does this).
However, you could design your application as a single page that uses a JavaScript framework (such as JQuery or AngularJS) so the browser doesn't actually change URLs. This would prevent the browser from tracking the interaction between the JavaScript code and the server. Then you can guarantee that the user can only view the "pages" in the correct order.
I have webservice which uses ASMX webmethod etc (I know, outdated), it is used to supply mobile devices with data for their apps.
Right now, users can login on any device at any time, as many times as they want. To make this product compatible with a new licensing model, we want to restrict users in logging in to multiple devices.
A user should only be able to be logged in at one device at a time.
I thought of the following solution: save the mobile device identifier last used in a request, and the time of the request in the database. If a user tries to login (within ~10 minutes) from another mobile device identifier -> login fails.
My problem: in which method do I put this code. I want to prevent duplicate code as much as possible.
I have 4 .asmx files with API's, I could put the code in the constructors of all the classes, but I'd rather not. Is there not some "Request_Start" that already has access to GET/POST parameters?
Please refer to:
When the same user ID is trying to log in on multiple devices, how do I kill the session on the other device?
I understand you're asking about ASMX, but I believe this will be a good starting point for you.
I had this same exact requirement, and came up with a pretty slick solution, demonstrated in the link above. In a nutshell, my requirement was to only have one user log-in happening at one time. If that same user ID tried to log in elsewhere, then it killed the session for the first log-in by checking for an existing log-in under a different Session ID (this enabled the user ID to be logged in from multiple instances of their web browser on their computer [same Session ID], which is common, but not from a different computer [different Session ID] (possibly due to someone that stole their credentials, for example)). Through modification of the code you could probably change the behavior of this - i.e., prevent the second log-in attempt instead of killing the first log-in that's already active and in use.
Of course, it may not fit 100% to what you're needing, so feel free to modify it to fit your needs.
I am confident my application is coded correctly (at least mostly), as it works about 98% of the time. However, about 2% of the time, I get what appears to be a valid auth token, but when I go to post a photo, I'm getting the following error "(OAuthException - #200) (#200) User must have accepted TOS". I have retry logic, but it gets the same error three times (so it's not a freak communication glitch).
I use the URL facebook.com/dialog/oauth to get the token, and then I use the C# Facebook client (Post method).
The other questions I've seen posted with this error appear to involve consistent failures, indicating an application error.
Is it possible that a person is shown the permissions page (on Facebook) and rejects it, so the user is then redirected back to your website, but with the Oauth error - which you need to handle.
Basically, I want to log in via Facebook, but I don't accept their conditions (eg. you might be asking for too many things). Thus I'll reject the login, and the source website (you) needs to handle the refusal.
After finally reaching someone at Facebook to talk with, it appears this may be an issue on their side- given the massive parallel processing needed to handle their user base, it is possible the auth token provided was not replicated to all other servers by the time my app (from a different location) tried to use the token.
The suggestion provided by Facebook was to allow more time in the retry process- while it is usually handled within a minute, sometimes it can take up to 30 minutes to replicate to all servers.
I've got a strange one to solve today. A client needs their site to not allow people being logged in, going to a different site, then still being logged in if they hit the back button in their browser.
Simple I thought... until I couldn't find a page event that got fired when the back button was pressed from another site.
I thought of just using JavaScript and working with the referrer object, but this won't achieve my goal as I need to access the .NET Membership system and log the user out of their session.
Has anyone got around this problem? If so, how? Any help would be appreciated, potentially I'm just missing something that I could achieve in the Global.asax? If it helps, I'm using .NET 4.5 / C#.
Reasoning:
Due to, say, if one operator went and left their machine unlocked, visited Google, then another operator went on the same machine maliciously and hit the back button to gain access to that operator's logon (the client is very security cautious)
So you would like to log out user whenever they leave your site? You cah have global javascript that sends a request to a server every minute saying "Hey, server, I'm here! I'm user Joe Blogs, i'm still on the site". If the server does not get this message from a user longer than a minute, log them out.
Overriding back button is just not going to work. What would you do if user opens up another tab/window and goes to google there?
Update:
you can try using .unload() from jquery to catch page leave. And destroy the cookies on that event.
However, when the machine is just left unattended, nothing stop malicious user to go grab the access.
Update 2 you can just set very short session life! if user is inactive (or left the page) - log them out. To prevent possible annoyance for logging out when user looking on the screen for too long (fills in very long form) - make javascript to do regular (every 5 minutes) to a server to a dummy page - to keep the session live while the page is loaded.
Here is the source: Force users to logout when they leave my php website?
There is perhaps a "magical" solution for the problem but the key thing here is in the reasoning: Operator A is not allowed to use the site with the credentials of Operator B.
From a client and server perspective there is no way that the server or client (browser) can tell that persons changed seats at whatever moment in time.
That's the problem you have to solve.
But perhaps implementing face-detection is a little over the top?
If you were designing the site from the ground up you can do this by adding a header to specify that you do not want caching.
Cache-Control: no-cache
Pragma: no-cache
But you would then have to have all your site access through a single page. The page need not be displayed the same and can contain different controls etc, but it's content would be decided by POST parameters rather than through the normal ASP.NET model.
e.g. Default.aspx and to navigate you would POST back at least two parameters. One would be the page to navigate to, and another would be an unpredictable token.
e.g. Token=3Zd2f4O61Z&Page=OrderHistory
Upon each page load you would validate the token and page title combination, and if OK you would display the page and generate new post-back data links for any navigation or actions you would like the user to take at that point. If the user were to try accessing the same page with the old token, it would expire the session and then log out the user. This is the most secure way to do this as then clicking the back button would prompt the user to resubmit their post data again. If OK was clicked, the browser would submit it but the server would recognise that the token was now invalid (as it has already been used, and discarded by the server) and then log out the user.
This method also protects against CSRF as you are validating a token in the payload of each request rather than just checking cookie values.
I know this won't help you unless you can reengineer your site, but I thought I'd add this solution in case anyone lands here with the requirement from the beginning.
You can have a landing page of your site to contain nothing by a JS redirect to reals homepage this way when person hits back button he will go back first to the damy redirecting page that move him back to home page.
But it will be possible to override this if user chooses to skip number of pages at once or just opens another window.
Could you provide further information about why exactly is its needed ? I think in your case, there is a possible solution of may be having a separate Database table or field for marking or flagging such users who have been redirected to another site just treat them as signed off and then once they hit your sites URL you can probably check for the flag and sign them back in, automatically.
JQuery unload() function will solve your problems as wel as the javascript window.onbeforeunload...