I've been thinking about Same Origin Policy and CSRF, and couldn't answer myself why web browser developers don't use a simpler solution.
Instead of disallowing cross domain scripts, why can't they allow any access to any site, but with an empty cookie jar? (or rather, a cookie jar that contains only the cookies of the current domain)
Same thing about any tag (img, script, etc.)
If any access is with no cookies, what CSRF can be done?
Regarding a cookie jar w/ only the cookies of the current domain: the cookies of the current domain may contain session information for example. This information could then be sent over the wire and result in session hijacking (for example).
Even if the scripts did not have cookie information, there could be other sensitive information on a website, perhaps visible through the DOM. This information could then be uploaded cross domain.
As an side, I don't think the same origin policy actually does anything to stop malicious hackers. As you said img's and scripts can make requests out. I can run a server that returns a 404, but keeps a log of the GET requests (for example: maliciouswebsitehere.com/fake404.html?bankaccountnumber=34398439843983&otherinformation=blah)
Related
Is it okay that a website displays the csrf_token as a URL parameter? I have a feeling that I shouldn't be able to see it, but I am no quite sure. If someone can clear this up a bit, I would be grateful!
No, It's not acceptable.
Passing tokens in URLs isn't normally an acceptable solution. Actually it's
in some cases considered a vulnerability.
What if the Website not running under HTTPS?
What if it's running under HTTPS but HSTS isn't enabled on the server? Then SSL-Stripping techniques would be possible and other MITM attacks.
Even if it's running under HTTPS and HSTS is enabled that won't solve the issue.
The token could be exposed in:
Referer Header
Web Logs
Shared Systems
Browser History
Browser Cache
For more information refer to:
Information exposure through query strings in url
OWASP CSRF Cheatsheet
The typical characteristics of a CSRF Token are as follows:
-Unique per user session
- Large random value
- Generated by a cryptographically secure random number generator
CSRF tokens in GET requests are potentially leaked at several locations: browser history, HTTP log files, network appliances that make a point to log the first line of an HTTP request, and Referer headers if the protected site links to an external site so it is not recommended.
HTTPS is slow to start up, especially on low-bandwidth and high-latency connections, or on low-spec machines. Unfortunately it seems to be the standard method for securing logins used by all major websites.
But a lot of websites we usually visit simply to read information. If we only occasionally want to make a write/update, then waiting to get logged in is an unnecessary time overhead.
The most upsetting example for me is:
Github. I often want to visit a github page just to read a project's overview or view a file. But I must wait for the SSL handshake, even if I don't want to do anything related to my personal account. Github always redirects my browser from HTTP to HTTPS. Why?!
I understand a secure connection is important to authenticate a user account. But when this impacts the user experience of simply viewing public pages, we should try to work out an alternative (and encourage major sites to adopt it).
Here is a possible workaround (1):
Allow users to make HTTP connections to our website, so we can present pages quickly without the need for an SSL handshake.
Allow the login to occur after the page has loaded. Perhaps an Ajax request over HTTPS could authenticate the user, and provide relevant updates to the page. (Is this fundamentally insecure? Edit: Yes, it is not fully secure, see answer below.)
Another alternative might be (2):
Instead of long-lived cookies over HTTPS, use a combination of long-lived one-time-key cookies for persistent login, and short-lived cookies for non-linear browsing, over HTTP. Replace them frequently. (This may be less secure than HTTPS, but more secure than normal long-lived cookie usage over HTTP.)
Do these solutions seem secure enough, or can you suggest something better?
(It might not be a coincidence that I am writing this from somewhere near Indonesia, which is a long way from the USA net!)
Workaround #1 in the question cannot provide full security to the first page, because a man-in-the-middle attack could have injected or modified scripts on the page before the login occurs.
Therefore we should not ask for a username/password on the HTTP page. However, the HTTPS Ajax operation might be able to inform the user that a persistent login session has/can be restored. (A script could then replace all HTTP links on the page with HTTPS links.)
But even if that succeeds, we still should not fully trust any user clicks or <form> POSTs originating from the first page. (Of course, requests to view other pages are fine, but it might be wise to reject updates to settings, password, and finance-related actions.)
This technique could at least be a way to perform the HTTPS setup in the background, without making the user wait for initial content. (StackOverflow uses something like this procedure.) Hopefully the browser will cache the HTTPS connection, or at least the keys, avoiding any delay on subsequent requests.
Here is one alternative I can think of, albeit slightly restrictive:
Allow browsing of public pages over HTTP, but don't perform any user login. This avoids all security concerns.
The 'Login' link would then send us to an HTTPS page, and may be able to recover the user's account automatically from a long-lived HTTPS cookie.
Make an option available "Always log me in through HTTPS", for users who are not bothered by the handshake overhead, and prefer to be logged in at all times. Note that a cookie for this setting would need to be set on the HTTP domain, since it needs to work without the user being logged in!
In reality, we would probably offer the converse: default to the existing prevalent behaviour of redirecting to HTTPS automatically, but provide an opt-out "Do not always switch to HTTPS for login" for those users wishing to avoid the SSL handshake.
But there are still issues with this approach:
Unfortunately cookies are not namespaced to the protocol (http/https). We can mark cookies as "secure" to prevent them ever being sent over HTTP, but some browsers will wipe them entirely if an HTTP request does occur. One way to keep the cookies separate would be to use different domains for unauthenticated and authenticated access to the site. But then we find ourselves violating REST, with two different addresses pointing to essentially the same resource...
Can this be resolved?
Hi I have recently read JSP and came across its technologies, mainly session. Under session, I read URL rewriting one of the method that was been done in order to maintain the session with the client. But since the URL rewriting changes the URL with the session ID and it can be visible to the client.
Is that not a security issue? Lets say for example, if any one note this session ID apart from the particular user, and can make a bad use of it? Or else there are techniques for preventing these?
Correct me if am wrong.
Certainly this is a security concern. If you quickly take note of the jsessionid value, either from a by someone else mistakenly in public copypasted URL or a in public posted screenshot of some HTTP debugging tool (Firebug) which shows the request/response headers, and the website in question maintains users by a login, then you'll be able to login under the same user by just appending the jsessionid cookie to the URL or the request headers. Quickly, because those sessions expire by default after 30 minutes of inactivity. This is called a session fixation attack.
You can disable URL rewriting altogether so that the jsessionid never appears in the URL. But you're still sensitive to session fixation attacks, some hacker might have installed a HTTP traffic sniffer in a public network or by some trojan/virus, or even used XSS to learn about those cookies. To be clear, this security issue is not specific to JSP, a PHP, ASP or whatever website which maintains the login by a cookiebased session, is as good sensitive to this.
To be really safe with regard to logins, let the login and logged-in traffic go over HTTPS instead of HTTP and make the cookie HTTPS (secure) only.
URL rewriting of session cookies is discouraged in most (if not all) security circles. OWASP ASVS explicitly discourages its use as it results in exposure of the session identifiers via an insecure medium.
When URL rewriting of session cookies is enabled, the URL could be transmitted (with the session identifier) to other sites, resulting in disclosure of the session identifier via the HTTP Referrer header. In fact, a simple request by a browser to a resource located on another domain will result in possible hijacking (via a Man-In-The-Middle attack) or fixation of the session; this is as good as a Cross Site Scripting vulnerability in the site.
On a different note, additional protection mechanisms like the HttpOnly and Secure-Cookie flags introduced into various browsers for protecting the session cookie in different ways, can no longer be used when URL rewriting of cookies is performed by a site.
I believe you're referring to cookieless sessions. Although I have seen it referred to as 'url rewriting' in Java circles.
There are some extra session hijacking concerns (and they apply across all web development frameworks that support cookieless sessions--not just JSP). But session hijacking is possible even with cookies.
Here's a pretty good in-depth article on MSDN about cookieless sessions and the risks/benefits. Again, these are all platform agnostic.
http://msdn.microsoft.com/en-us/library/aa479314.aspx (toward the bottom)
This is what I came accross checking the OWASP specifications for URL rewriting and it Exposing session information in the URL is a growing security risk (from place 7 in 2007 to place 2 in 2013 on the OWASP Top 10 List).
Options for managing URL rewriting include :
disabling them at the server level.
disabling them at the application level.
An attractive option is a Servlet filter.
The filter wraps the response object with an alternate version, which changes response.encodeURL(String) and related methods into no-operations.
(The WEB4J tool includes such a filter.)
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
We recently changed our login to use HTTPS, and we are experiencing issues with the login.
After the login, the user is redirected to an unencrypted (HTTP) page. When it reaches this page, the site checks if the user is logged in. It creates a new session and it appears that the user is not logged in, and thus our user is redirected to the login page. If the user logs in again, it will work.
The cookies are not set as https-only, but it seems like they don't work on http pages.
Does anyone know why this might be happening.
Edit:
I should have mentioned that the page that displays the login is on a different URL. (There is a login page from the machine running the tomcat instance, but the marketing site is on a wordpress install and uses a different domain).
I can't use the HTTP request first method to set the cookie, because the default Internet Explorer settings prevent the session cookie from being saved.
We have this problem with our app. We wanted a similar behavior of logging in via https, then redirecting to an http page.
The issue is that when Tomcat creates the session under https, it creates a secure cookie which can't be read in http. Note that this keeps getting filed as a bug in Tomcat and getting marked as "not a bug".
The solution we ended up is based on the message in this forum
http://forum.java.sun.com/thread.jspa?threadID=197150&start=0
Quoting from the forum thread: "One way to maintain the session in Tomcat, when the session cookie is getting created in SSL mode is to trick the browser by creating the non-secure cookie, when the secure cookie is getting created." This is accomplished via a filter that wraps the request and overrides request.getSession(). It's worked very well for us.
As a side note, redirecting from an https to http page will pop up a warning message in some versions of Internet Explorer "You are about to be redirected to a connection that is not secure." The only way we found to avoid this is to have the redirection be done with a meta refresh tag. Specifically, return a blank page from the original https request with a meta tag that refreshes to an http page. This avoids the warning message at the expense of making the code slightly more convoluted.
(I just noticed some of the advice here is a repeat of an earlier answer -- I apologize, but will post anyways since it is from direct experience).
Edit: I see in your comments you have two domains, which complicates the use of cookies. Can you use a proxy or web server such as Apache to present just one domain to the end users?
When using https tomcat establishes the jsessionid through a secure cookie, which cannot be transmitted through a non-secure connection. So when you fall back to http the session is lost.
The workaround (which I haven't done it myself) seems to be establishing the session through a http request before redirecting to https, and then setting a filter in the HttpRequestWrapper to plug into the nonsecure cookie.
I don't know much about this, but here are a couple of references:
http://forums.sun.com/thread.jspa?threadID=197150
http://tp.its.yale.edu/pipermail/cas/2006-March/002356.html
If you've verified the secure-only flag is off, and that the first cookie is being dropped correctly - I would guess that that there may be a path issue which is preventing the cookie from being presented again.
From ha.ckers.org/xss.html:
IMG Embedded commands - this works
when the webpage where this is
injected (like a web-board) is behind
password protection and that password
protection works with other commands
on the same domain. This can be used
to delete users, add users (if the
user who visits the page is an
administrator), send credentials
elsewhere, etc.... This is one of the
lesser used but more useful XSS
vectors:
<IMG SRC="http://www.thesiteyouareon.com/somecommand.php?somevariables=maliciouscode">
or:
Redirect 302 /a.jpg http://victimsite.com/admin.asp&deleteuser
I allow users to post images in the forum. How can this be protected against?
I'm using Java Struts but any generic answers are welcome.
If you follow the rules of the HTTP specification, such a kind of attack will make no harm. The section 9.1.1 Safe Methods says:
[…] GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.
Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.
So all requests that change data on the server side should only be allowed via POST. And even there you should only allow those requests that your system has authenticated by generating tokens that are only valid for a specific form/action.
This attack is simply an HTTP GET request made to any URL. You cannot reliably block it by prevent certain <img> tags.
Instead, you need to make sure that your website has no targets (URLs that respond to GET requests and change things)
If there aren't any "juicy" URLs that respond to HTTP GETs (not POSTs) and change data, the attacker will have nothing to attack. (<img> tags cannot be used to create HTTP POSTs)
Cross-site scripting is one reason why you should not allow forum users to post images by linking to images outside your site.
Image posting should be provided by allowing users to upload the image file to your site and using internal relative URI.
By injecting an <img> tag someone can bypass referer based XSRF protection for a GET request. The reason why is because the referer for the GET request produced by the <img> has the same referer as the host its self. So this would bypass code checking to see if the referer and the host where different.
You shouldn't allow people to put html on your page. In this case you should let users upload them and then host images locally. If you really want people to put IMG tags on your site, make sure the URL isn't pointing to your server, because this what an attack would do! Also don't use referer based XSRF protection, use token based. <img> tag injection cannot bypass token based xsrf protection.
No one seemed to mention that the threat in allowing people to post images is not to you, it's to other sites.
If you allow people to post images but your site has no XSRF vulnerabilities, your site is not in danger; other sites with XSRF vulnerabilities are, as your users will unknowingly make requests to the other site via the embedded image when they visit your site. The malicious <img> tag will look something like this:
<img src="http://my-bank-website.com/withdraw_money.php?amount=100000&account=mandy-the-hacker" />
Note that this is not a real image, but the browser will not know that, so it will make the request anyways, transferring $100,000 to mandy-the-hacker's account, assuming the user is currently logged on to my-bank-website.com. This is how XSRF vulnerabilities work.
The only way to prevent this is to force users to upload images, rather than providing URLs for them. However, the malicious user could still just provide a link to the XSRF vulnerability, so removing the ability to provide URLs doesn't really help anything; you are not really harming the other site by allowing <img> tags, they are harming themselves by not using user-specific tokens in forms.