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.)
Related
Scenario: the web page I'm on uses HTTP. It includes a form to login. The form action uses HTTPS.
Question: are my login credentials secure, or must the page I'm on use HTTPS also?
Follow-up from: https://twitter.com/falkowski/status/525354785437147136
Technically, it is only the form action that requires HTTPS.
However, IE in particular complains mightily when you try to mix secure and insecure resources. In addition, having such a configuration indicates that the writers of that service are being lazy.
The design would preclude the latest security configurations such as Strict Transport Security & Perfect Forward Secrecy and will also prevent the site from using SPDY. Bad design.
Even worse from a user perspective is that it is almost impossible to check that the site is using a secure connection and it would be trivial for that form submission to be changed to non-secure without anyone being any the wiser. Bad design!!
I would point out though, that with was common practice a few years ago when HTTPS was a significant overhead on web servers. Things have moved on though and this is no longer the case.
Reference from another thread: Is it secure to submit from a HTTP form to HTTPS?
TLDR: the submission itself is technically secure, but because the surrounding page is susceptible to a MITM attack it's not.
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?
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)
APIs with terrible security are common place. Case in point - this story on TechCrunch.
It begs the question, how do you balance security with performance when it comes to SSL? Obviously, sensitive information such as usernames and password should be sent over SSL. What about subsequent calls that perhaps use an API key? At what point is it okay to use an unencrypted connection when it comes to API calls that require proof of identity?
If you allow mixed content, then a man-in-the-middle, can rewrite mixed content to inject JS to steal sensitive information already in the page.
With cafés and the like providing free wireless access, man-in-the-middle attacks are not all that difficult.
https://www.eff.org/pages/how-deploy-https-correctly gives a good explanation:
When hosting an application over
HTTPS, there can be no mixed content;
that is, all content in the page must
be fetched via HTTPS. It is common to
see partial HTTPS support on sites, in
which the main pages are fetched via
HTTPS but some or all of the media
elements, stylesheets, and JavaScript
in the page are fetched via HTTP.
This is unsafe because although the
main page load is protected against
active and passive network attack,
none of the other resources are. If a
page loads some JavaScript or CSS code
via HTTP, an attacker can provide a
false, malicious code file and take
over the page’s DOM once it loads.
Then, the user would be back to a
situation of having no security. This
is why all mainstream browsers warn
users about pages that load mixed
content. Nor is it safe to reference
images via HTTP: What if the attacker
swapped the Save Message and Delete
Message icons in a webmail app?
You must serve the entire application
domain over HTTPS. Redirect HTTP
requests with HTTP 301 or 302
responses to the equivalent HTTPS
resource.
The problem is that without understanding the performance of your application it is just wrong to try and optimize the application without metrics. This is what leads to decisions by devs to leave an API unecrypted simply thinking it's eeking out another 10ms's of performance. Simply put the best way to balance security concerns versus performance is to worry about security first, get some load from real customers(not whiteboard stick figures being obsessed over by some architect) and get real metrics from your code when you suspect performance might be an issue. I have a weird feeling that it won't be security related.
You need to gather some evidence about the alleged performance issues of SSL before you leap. You might get quite a surprise.
We have our site integrated as an iframe into another site that runs on a different domain. It seems that we cannot set cookies. Has anybody encountered this issue before? Any ideas?
Since your content is being loaded into an iframe from a remote domain, it is classed as a third-party cookie.
The vast majority of third-party cookies are provided by advertisers (these are usually marked as tracking cookies by anti-malware software) and many people consider them to be an invasion of privacy. Consequently, most browsers offer a facility to block third-party cookies, which is probably the cause of the issue you are encountering.
From new update of Chromium in February 4, 2020 (Chrome 80).
Cookies default to SameSite=Lax. According to this link.
To fix this, you just need to mark your cookies are SameSite=None and Secure.
To understand what is Samesite cookies, please see this document
After reading through Facebook's docs on iframe canvas pages, I figured out how to set cookies in iframes with different domains. I created a proof of concept sinatra application here: https://github.com/agibralter/iframe-widget-test
There is more discussion on how Facebook does it here: How does Facebook set cross-domain cookies for iFrames on canvas pages?
IE requires you to set a P3P policy before it will allow third-party frames to set cookies, under the default privacy settings.
Supposedly P3P allows the user to limit what information goes to what parties who promise to handle it in certain ways. In practice it's pretty much worthless as users can't really set any meaningful limitations on how they want information handled; in the end it's just a fairly uniform setting acting as a hoop that all third parties have to jump through, saying “I'll be nice with your personal information” even if they have no intention of doing so.
Despite adding SameSite=None and Secure in the cookie, you might not see the cookie being sent in the request. This might be because of the browser settings. e.g, on Brave, you have to explicity disable it.
As more and more people are switching to Brave or block third party cookies using browser extensions, you should not rely on this mechanism.