I received results back for an ethical hack assessment for one of my asp.net webforms sites. One of the items was a multi step way the hacker changed the request to display a page he shouldn’t have had access to with his user privileges. Below are the steps he performed to execute the hack:
1) logged in using Admin level rights.
2) navigated to page ‘A’.
3) using his Burp tool, saved a copy of the page headers.
4) he then logged in using a User account which shouldn’t be able to see page ‘A’.
5) goes back to the home page to get a fresh request.
6) using his Burp tool, opens the request headers for the home page and replaces them with the contents he saved from page ‘A’.
7) he continues on with the request and is now able to see the contents of page ‘A’.
I tried to programmatically check the request.url and compare it against what pages the user has access to but the hacker said that didn’t fix it.
Is there a built in way to prevent this in ASP.NET 4.x? Is there some web.config property I can set to stop someone from changing the request headers and performing this kind of hack?
Update: This was happening because the username and usertype was being stored in session variables after authentication. Once the hacker gained access to the session, they replaced the session of the ‘User’ with the session of the ‘Admin’ account and it was just as if the Admin was logged in. The fix was to not store the username and usertype in session variables. I also created a table with the pages that each usertype was able to access and checked that each time a user comes to a page. If the usertype does not have access to the page, they get redirected back to the homepage. Both of these fixed the issue and eventually passed the ethical hack.
Related
Here is the scenario...
I have a site:
http://internet.com
and I set a token(cookie, something like that) from http://internet.com when a user has SUCCESSFULLY logged in.
I also have http://web.internet.com.
On http://web.internet.com I want to display data to users that have that token/cookie/etc available to them.
Here is the use-case
user logs into http://internet.com (asp.net framework hosted on different server - this is our primary product that requires a subscription / username & login )
user then has access to a section that is hidden from plublic view on http://web.internet.com (wordpress site hosted on goDadday - this site contains a knowledge base that we do not want to make public unless they have done [XXXXX] )
both sites are hosted independently of each other and do not share a common username and password
======
Another scenario is to set up wordpress to allow a specific section as a jsonp response. but only if the user is logged in at http://internet.com to allow the user to have access to the jsonp response located at http://web.internet.com
Any ideas from you beautiful people?
It really depends on the level of security you require. You can log a user in to a Wordpress site without a password by using wp_set_auth_cookie, however if you are just validating that a user is logged into the ASP.NET site and then using JSONP to load a page that set's the auth cookie, it will work, however you definitely have some security gaps.
A better solution would be to set a domain level cookie for .internet.com with a token that can be read by any server in your domain. The Wordpress site could then check is_user_logged_in(), and if not take that cookie value and make a back end call to the ASP.NET site to verify its authenticity, and then call wp_set_auth_cookie(). A simple web service would likely be the best option. You would still need some level of mapping between usernames on the ASP.NET and Wordpress site however to know which user_ID to pass.
I've got some things in my mind, I thought I'd ask the veterans here. I'm creating a website using Razor syntax and WebMatrix. I'm currently implementing a user login system into it. So my questions are:
In WebSecurity, when a token is generated (for creating new account, or recovering password, etc.), is this token a public key? Can it be safely emailed to the user over unsecured network or email. Is it a good practice (or useful) to further encrypt this token?
I've set my secured pages to not to cache on web browser, i.e. pages which are accessed by user after he signs-in with his password. I think its a necessary action because when a user logs out, I don't want the user to press the browser's back button and see the secured pages again. So I set all the secured pages' expiry as follows:
Response.Expires = -1;
Response.Cache.SetNoServerCaching();
Response.Cache.SetAllowResponseInBrowserHistory(false);
Response.CacheControl = "no-cache";
Response.Cache.SetNoStore();
My question on above is that if I set my pages to expire immediately, the browser does not cache anything and reloads the page every time user visits it, does it mean that the browser will not even cache the linked style sheets, script files and images? I've set my images to preload so that the website's presentation works smoothly; will the immediate-expiring of webpage cause these images and everything to be loaded all over and over again on each page?
Thanks.
It's not a "public token", in the sense that anyone who gets access to that token can use it to reset the user's password and log in. So it does need to be sent securely, and the reset link should require SSL.
No, the setting of cache expiry on specific pages will not affect the caching of other content. You can set the cache policy/headers of static content using IIS manager, or in the web.config.
I want to save the page url, to a log file for example, that a user browses during a session and suggest him/her next time. What's the best scenario?
The correct scenario is to connect the user cookie with his data on a database on server and there keep the last visiting page.
An alternative for a site with few pages (and not database), is to have a number for each of your page and save this number only on the cookie, and then know what page to show base on this page number. Eg the 56 is for page contact.aspx
So the next time it will visit your page you find that parameter and make your suggestion.
To save the full url page on the cookie is something that I do not suggest because you make the cookie too big in size and that can lead to other problems (think that all cookies are follow the user on all calls, even the calls to see an image).
Of course you need to make this suggestions only for new sessions - and if the user is not on the same page. Think also what happens if a user have open 10 pages of your site opens and the session ends on all after some time of inactivity... Think again the user interface, the common way for that is the full history of what he see at the end of the page.
My website have a home page, and I would like to cache that page for anonymous users, and set it as "private" for authenticated users (so they save it on their computers, nowhere else).
So, if the user is anonymous I want to save the page in the server cache, and also in the browser cache using Cache-control:public, max-age=60 and Vary:Cookie, so if the browser gets authenticated and send a cookie, the browser won't reuse the former stored page.
If the user is authenticated, then I do not want the page be stored in the server, but I do on the customer browser using Cache-control:private, max-age=60.
I have been trying with several combinations with OutputCacheAttribute and Response.Cache but I cannot get it right.
What would be the best way of doing it?
Regards.
You may try implementing a VaryByCustom rule that will distinguish between anonymous and authenticated users. Here's an example that should put you on the right track.
My bank's website has 2 login pages for online banking. On the first page, I enter my username. If I don't enter a valid username, I get an error message, and do not get to the 2nd page. The 2nd page displays a picture based on my user name, and has me enter my password. If I manually type a URL to a page inside the site after entering my username but before entering my password, I am redirected back to the first login page.
Is there a good way to implement this in ASP.NET with Forms Authentication? I only get 1 loginUrl in my web.config.
I am fairly certain my bank uses Java.
I do not find this a good idea, because this way any attacker know if the user name is the correct, then its need to know the password.
Second reason is that is more complicate and you need to be sure that you do not forget something on the way to login.
Third reason is that is not the common way to login, so people did not have use to it.
If you like to make the same, you need 2 pages, in the first you ask the user name, then you search on your local database if this is a valid user, then you keep this user name on a variable that you send on the second page that is the actual login. On the second page you have a common asp.net login module, but you have hide the user name, and at the same time you have set it with the value from the previous page. And then the rest is up to you.
Hey I know the bank on this one. Well provided it's the same bank there is another page that the user has to visit if they are on a computer thats never accessed the login before. Once the enter the user name they visit a question answer page where the question is a random one they picked when they first signed up or at least when they thought up this cockeyed login page. Then they visit the password page.
You can implement this yourself if you are using the built in AspNetSqlMembershipProvider provider you can customize the built in login control and override the OnLoggingIn method. You can then do what ever checks you need on that login and move it to another page. On the next page you can override other methods the same way like: OnAuthenticate, and OnLoggedIn while still using the built in control (but customized) if needed. Then you can set the login page in your web.config to your first login page. You can see MSDN for other methods as well.
Now as already pointed out this is not ideal because it's not typical and most users will not understand what is going on or think it's flaky (just like i do about the bank). Not to mention you will need to do additional checks similar to how that bank is doing it to make sure everything is legit coming from the client. So in the end I wouldnt recomend it, it's to much hassle for the end user mainly.