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.
Related
I have a Wordpress website and a Chrome Extension. If the user logs in on the website, I want the Chrome Extension to be aware of that (and vice-versa). The Chrome Extension won't have a login form in it; the user will always log in through the website login form.
When you log in on the website, Wordpress by default sets its authentication cookies to identify the user. What I initially had in mind: I would also like to return some kind of access token, which I would store somewhere where the extension can find it and use it to make authenticated requests to the Wordpress REST API. But.. where do I store it (in a safe manner) so I can find it within the extension?
Perhaps I should try a different approach?
Thank you!
What you could do, the simpler way:
create an Ajax action or a REST API route
as you can read in the documentation, the authentication is cookie-based. So once the user is logged in from the WordPress login form, the authentication cookie is added to your browsing session
without overrides, the cookie will also be forwarded when using JS HTTP queries (eg ajax)
your route could check something like is_user_logged_in() or wp_get_current_user() like available methods. And return the result (among other things if needed) to your plugin JS
you may need to change the WordPress cookie configuration, so they can be accessed from anywhere (any domain), check this.
Better way:
would be to use a plugin like this to implement REST API Oauth2 authentication
user should be able to login directly from the extension window (need development), and then use a refresh token feature to keep the user logged in.
I believe you may also need to update your actual login form, if its classic or OAuth rest API login, should be able to send back the required OAuth token (access and refresh tokens), to the frontend (then stored in local storage or else) to be used by the extension. To prevent having to log in twice.
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.
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.
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.
I have a ASP.NET website where after a specific user action, I have to issue a new AUTH cookie almost identical to the one the user already currently has. I'm having trouble finding out whether the current AUTH cookie is supposed to be persisted or not. Any ideas on how to do this?
If the cookie expiration isn't set, then it's session.
If you are trying to discover it's life via the browser, you can use firebug with the firecookie plugin. Or the web developer tool will also enumerate all the cookies on a page.
Any cookie that is not session will have Expires field. If you send it into feature date - you will get it "permanent" until the time expires. If you want to maintain "permanent" cookie status you would refresh it on next user login and shift it further into the future. One month is usually enough