For many applications that I've ever worked on. After logging successfully and session's still active, if users try to access signin/signup page by directly using browser address bar, they'll be redirected to dashboard or home page. I just follows some existing applications such as Goolge perhaps.
But what's the main reason of this flow? Does it raise any security risks if users can still access signin/sigup while their sessions are still active?
The decision to have separate login page or redirection of user to another page depends on the use case or requirement that you have for your website. It is directly related towards the functionality you want to provide to users.
It is mainly for bringing functional separation such that the login page is specifically for logging in and dashboard page or home page is to show the the account details or other related information of your home page. It also can be used for security purpose.
Functionally, having user login and dashboard page on same page can have its own challenges based on the other processing that is being done by you as per your use case. Consider a scenario where an email shall be sent whenever you login and also some additional processing is done based on the login procedure. Each refresh on the posted page would log the user back in. In such a case, every refreshment of the dashboard page would trigger an email and also does additional processing which may not be desired. In the perspective of security, based on your requirement, you may redirect URL based on PRG(Post-Redirect-Get) pattern to a restricted page or guest user page rather than having the main home page when an unauthenticated user logins or based on the subscription type of user.
It should also be noted that having a login mechanism integrated into the main page also has an advantage based on your website requirement as it provides the ability to login without losing the context of what the user is doing which is purely dependent on the requirement for your website. However, a separate login page has the advantage of being easier to implement and also for the pages that have sensitive information, you can simply redirect to the login page, rather than having to worry about rendering UI without the context of a valid session.
This is more of a usability feature than a security one. Developers put a bit of additional effort to implement stuff like this. Here is an example how they do it.
You should probably look into "OAUTH2" or similar authorization (beware not authentication) software, that might spread the light its about tokens and who might use them where and when. (pretty shady that's why im gonna leave that link here but you should really dig deeper for yourself)
https://docs.apigee.com/api-platform/system-administration/using-oauth2
Related
I am developing a MERN app, where users share things with a link to access those things.
So these things get displayed to other users, and they can click on them, and they get redirected to that link.
This doesn't seem secure as some users can post things with malicious links.
Is there a way to verify that a link is secure and so validate the thing before it gets posted?
This isn't possible in an automated way. Links don't include any information about themselves other than the URL they point to.
You need a list of "malicious" URLs to compare against in order to achieve this. There are services that provide such databases. But this is a never-ending game of cat-mouse.
For example, if I have a malicious website, I don't have to share the URL to my website directly, I can use URL shortener service (bitly for example) that then redirects users. This way, I easily circumvented your protection.
That's the reason browsers have their own "malicious websites" list, since they have access to the final URL you're visiting.
In short: no, there's only limited protection you can offer.
The best you can do is warn the users they're leaving your site, like Discord or Facebook do (and they do that because they can't solve this problem either).
I'm working on a really simple web site. I usually do a full blown admin to edit the site, but this time I thought about editing in place (contenteditable="true").
To simplify login for the user, I'd like to just give him a password that he can type in the address bar to log him in, instead of the usual login form. So he would visit domain.com/page?p=the_password and then I would store his data in a session and give him a cookie with a session id (usual stuff) and redirect him to domain.com/page.
How safe / unsafe is this? I'm doing this in PHP, but I guess it applies to any server-side language.
Your login idea is unsafe: URLs for requests end up in web server logs and other places besides, so that means passwords will end up in web server logs.
Your "contentedittable" idea is probably unsafe, but in a more subtle way. It's also (again, probably) non-compliant with the HTTP specification.
GET requests should always be idempotent. This is because user agents (browsers, caches, etc...) are allowed to reissue the same GET request any number of times without user consent. One reason why a browser might do that is because the user pressed the back button and the previous page is no longer in the cache. If the request is not idempotent then issuing it a second time may have an unexpected and unwanted side effect.
It sounds like your "editing in place" feature might not always be idempotent. There are many kinds of simple edits which are in fact idempotent so I could be wrong, but as soon as you have for example the ability to add a new item to a list via this kind of interface it's not.
Non-idempotent requests should be issued through methods like PUT, POST, and DELETE.
To add to #Celada answer. The URL will be stored in the browser history or network caches/proxies, so the password can leak in this way. Also it would be trivial to login a random Internet user as someone else (Login Cross Site Request Forgery attack), by for example having a web site with an img element pointing to domain.com/page?p=the_password
You don't write about this, but once the user is logged in your scheme needs to protect against Cross Site Request Forgery (so a random page can not perform admin actions on behave of the logged-in user).
Same Origin Policy(SOP) is often mentioned together with Cross Site Scripting(XSS). But it seems that in the world with SOP, XSS still happens from time to time.
So I am never clear about what exactly kind of attacks do Same Origin Policy prevent?
In other words, imagine a world without SOP, what other power a malicious attacker could gain compared to the real world with SOP?
I read on this website(http://security.stackexchange.com/questions/8264/why-is-the-same-origin-policy-so-important) that "Assume you are logged into Facebook and visit a malicious website in another browser tab. Without the same origin policy JavaScript on that website could do anything to your Facebook account that you are allowed to do.". This actually makes me even more confused because I have never heard of any mechanism for webpage in one tab manipulating other tabs even from the same domain.
It is also mentioned (more explicitly) here (http://javascript.info/tutorial/same-origin-security-policy) that SOP prevents script in one window to manipulate DOM elements in another window. But I really cannot relate the example to what is explained (what does window mean here? it seems that the example is talking about iframe).
To sum up, can anyone give some concrete examples of what can happen if there were no SOP?
Also, I am curious about how script in one window can manipulate DOM elements in another window assuming the two window are from the same domain. But this is not the main course of this question
Thank you!
I have never heard of any mechanism for webpage in one tab manipulating other tabs [...] it seems that the example is talking about iframe
iframe is the easiest but not the only way of getting cross-window scripting. Another way to do it would be for the attacker page to window.open a document from facebook.com into a new tab. Because open returns a handle to the tab's window object, it is possible for script in one tab to interact with content in another tab.
Without the SOP, that script could fill in and submit forms in that tab on your behalf.
XSS still happens from time to time. So I am never clear about what exactly kind of attacks do Same Origin Policy prevent?
Without SOP, every web page is vulnerable to XSS and no-one can ever be secure.
With SOP, web pages are secure against XSS unless their authors make a mistake. XSS still happens from time to time because site authors do, unfortunately, make mistakes.
One example: for malicious web page it would be possible to make some javascript ajax requests to other web page where the user is already logged in the user's context. This other page would assume that the request comes from authorized user.
For example malicius script could make some ajax calls to Facebook and post new status or to bank transaction service and make a transfer if only the user is logged in to Facebook or his bank. People usually open many pages in browser tabs at the same time, so it would be very probable that someone browsing the malicious web page is at the same time logged to some sensitive service that could be hacked that way.
I initially designed my site to show a login box at the top of the page if the user was not authenticated (e.g. how reddit.com works).
I encountered a user who was having trouble with their browser's storage of their password because after a password change because their browser had stored their login information at different urls on the website. Even after the user typed correctly the new login information at one url, and the browser updated it, there would be other urls at which the browser had the incorrect login information.
This would also cause problems with sites that have a login box on their main page, and a special login page -- especially if the user front page login box is sent to the login page.
Is this a small enough case not to bother with, or should there only be one url at which a user can login to prevent this problem, especially for less technically-savvy audiences?
There should be one login page that every other page accessible sans login links to. It standardizes the process of logging in and reduces the kind of confusion your user experienced. It conforms to a convention that all the browsers are using with respect to saving passwords as well. Don't really see how you can go wrong that way.
Most sites use a single "sign in" button that takes you to the canonical login page.
If you want a signin box on every page that the browser can remember, consider using an iframe to hold the form.
I believe that if there is any way to use only ONE login location you should try to do it that way.
As you yourself said it's quite hard for browsers to determine what to do with stored passwords for sites with multiple login locations. There are possibly other problems and all of them are solved by having exactly one login location.
If you need to provide login from more places, just use redirection. But getting "in" your system should be done from one single place.
Just have one login page and have the other pages on your site linking to it. It keeps it simple for end users as there is only one page and easy for you to manage as you one have one login page.
Is it possible to secure only the Login.aspx page (and the postback) and not the whole site in IIS?
We are looking to do this specifically with a SharePoint site running Forms Based Authentication against our Active Directory.
Links to this will be helpful.
This is what we have done so far:
1. Setup SharePoint to use FBA against AD.
2. Moved Login Page to Secure/Login.aspx
3. Set the appropriate Login url in web.config as https://..../Secure/Login.aspx
This is not working and help is needed here.
However even if this works, how do we get the user back to http from https?
There's not a whole lot of point. If the only thing that's encrypted is the Login.aspx page, that would mean that someone could sniff all the traffic that was not sent through the login page.
Which might prevent people from getting user:pass, but all your other data is exposed.
Besides all the data which is exposed, and the user's operation which can be changed en route, the user's session id (or other authentication data) is sent in the clear. This means that an attacker can steal your cookie (...) and impersonate you to the system, even without getting your password. (If I remember correctly SPSv.3 also supports builtin password changing module...)
So I would say that this is not a Great Idea, unless you dont care about that system very much anyway.... But then, why bother with authentication at all? just make it anonymous?
I agree with AviD and Dan Williams that securing only the login page isn't a great idea because it exposes other data after leaving the password page. However, you can require SSL for only the login.aspx page via the IIS Manger. If you navigate to the login.aspx page in IIS Manager (I believe it's under /_layouts), you can right-click on the individual file and select Properties. From there, go to the File Security tab and click on the Edit... button under Secure communications. There, you can check the Require secure channel (SSL) box, and SSL will be required for that page only.
I'm not positive about getting the user back to http from there, but I believe its default behavior is to send you to the requested page if the login is successful. If not, I would think you could customize where the login page sends you on a successful login.