I have tried many ways to use the httponly flag to prevent XSS attack, but all failed.
Common way is to set use HttpOnly=true in context.xml
For test the result: in the java code set two test parameters in the cookie and in front jsp file include javascript to alert thedocument.cookie, the two test parameters set in java code are get and show in the alert.
Java code:
Cookie cookie = new Cookie("httponlytest","testsss");
response.addCookie(cookie);
Cookie cookie1 = new Cookie("testhttponly","successfu");
response.addCookie(cookie1);
javascript in jsp file:
alert("cookie------------"+document.cookie);
Is there anything i did wrong?
If you know how, it would be very helpful.
For others who do not know HttpOnly:
HttpOnly=true is a relative new attribute to make a cookie in the browser inaccessible to JavaScript.
So it is a browser-only security (XSS) technique to prevent accessing JSESSION_ID (hijacking java sessions) and such.
So you could always set the HttpOnly attribute in the Cookie itself. For the Java session ID it is now default I think, at least it should be.
<Context useHttpOnly="true">
This seems to work only for JSESSIONID. I just found this in SO.
Recently I was dealing with http-only=true cookies. During my research i found that Mozilla and Chrome do not allow java applets to use http-only=true cookies. I was getting issue in accessing the JsessionidSSO cookie. During my research on bugs of JAVA i found this bug
While in IE there is no issue in reading the cookies as IE has provided InternetGetCookieEx() API's to access http-only cookies and added the flag INTERNET_COOKIE_HTTPONLY available only IE8 and above versions. So the problem of accessing the http-only cookies still not solved as java proposed the fix in java 7 update 40 while the current version is java 7 update21.
Related
We have a Vaadin Flow 14.x enterprise app and a recent security review highlighted the lack of HttpOnly flag being set with the JSESSIONID cookie. How do we set this flag with Vaadin Flow 14? I've searched quite a bit and have not found any references to this.
Our app uses embedded jetty, but that probably doesn't matter in this case as its Vaadin that's setting JSESSIONID from what we can tell.
SOLUTION
The solution as described below is to configure embedded jetty to set HttpOnly. In my case I did this via:
WebAppContext context = new WebAppContext();
context.getSessionHandler().setHttpOnly(true);
The key is to configure this through Jetty. Vaadin is just using javax.servlet.http.HttpSession without directly touching any low-level session management details such as cookies.
[Updated - see comment at end]
Google will be changing the behaviour of its Chrome browser so that cookies will no longer work when hosted in another domain's IFRAME unless the cookies are explicityly set to SameSite = None, and Secure.
To this end, we made this change in our ASP.NET MVC code. We have some logic around when to set this (only for partners that we've agreed to work with), so we have this conditional logic:
if (isSameSiteCookieEnforced)
{
cookie.SameSite = SameSiteMode.None;
cookie.Secure = true;
}
We tested this in our DEV, QA, STAGE environments and it works perfectly. In Chrome's developer tools (Application > Cookies), you can inspect the cookies and see that they are all marked as Secure, and have None in the SameSite column.
However, when we rolled this to our PROD environment, we get different results using the same browser: the cookies are marked as Secure, but the SameSite value is empty.
What we checked:
Load Balancer: we isolated this and navigated direct to a single web server, same result
Installed .NET frameworks: in all environments, we've installed 4.7.2 and 4.8
Addressed .NET framework: in all environments, the web.config stipulates 4.7.2
Code: we retrieved the relevant DLL from PROD and inspected with ILSPY. It contains the above code
Currently at a bit of a loss to explain how the cookies could lose the "SameSite" property. Navigating to chrome://flags and filtering on SameSite we're showing the three settings to be "default", so Chrome shouldn't be affecting anything differently from one environment to another.
Update
Our ASP.NET MVC application uses an IHttpModule and as one of the last steps in the EndRequest method we trace out the cookies. You can clearly see that they are set with SameSite=None and Secure=true. But, when they arrive at the browser, the SameSite property has been stripped.
If you are conditioning on whether the new SameSite behavior is enforced, you will want to test the behavior with the chrome://flags entries same-site-by-default-cookies and cookies-without-same-site-must-be-secure set to both "Enabled" and "Disabled". If they are set to "Default", there is no way to tell what the behavior is. It could be on or off, depending on the random seed determined on startup, since the features are currently in a fieldtrial (A/B testing) on Beta. See the second bullet list in "Launch Timeline" here: https://www.chromium.org/updates/same-site
Found the issue - turned out that we were missing a Windows patch.
I have an existing website and suddenly some days ago I can't use Google Chrome anymore for developing. When I use a standard edit and create page, I get the above error. But i'm not getting it in Internet Explorer. I use Windows 10 (all updates installed) and VS2013 with Update 4. The project is the latest MVC version. I even checked the web.config but nothing is changed. I deleted all history, cookies, passwords etc.
Anyone any idea?
I had the same problem. For me the solution was to both clear my browser cookies and to disable Adblock. Other addons may have the same effect. I believe the problem is limited to the Visual Studio / Chrome development environment and will not occur in production regardless of whether the end user has Adblock enabled or not.
Do you have a
<httpCookies requireSSL="true" />
in your Web.config? Change that to false. Then in your transforms files (Web.Prod.config, and other environments that have SSL):
<httpCookies requireSSL="true" xdt:Transform="SetAttributes" />
I'm also having the same issue in recent weeks, but it's also extending cross-browser after originating from Chrome. What's even stranger is that it still works flawlessly with the identical project on a different machine using all browsers.
I have gone so far as to uninstall all extensions, delete all cookies / data, sign out of Chrome completely and re-install it. Problem still persists.
On deployment to Azure websites the problem isn't present on any platform. My current work-around is to Ctrl-F [ValidateAntiForgeryToken] and comment out every occurrence, and re-enable it upon deployment. Annoying, but it works.
This was happening to me in Chrome, and seemed related to using the 'remember me' checkbox on login forms, and closing then re-opening the browser. The token was present on inspecting page source, but was reported as being not present during debugging sessions in visual studio. By clearing the browser cache and not checking the 'remember me' box I did not get the problem - but I don't fully understand why!!
My steps to reproduce the bug in Chrome:
Sign in to your MVC web application, clicking on 'remember me' to make it checked
Close browser
Open browser to your current retained session
Try to sign out - error happens here.
Anyway, the following solution worked for me. Inside your MVC view form, try replacing this:
#Html.AntiForgeryToken()
with:
ViewContext.Writer.Write(Html.AntiForgeryToken().ToHtmlString());
Are you on cloud platform ? chrome emits cookies from cloud domains hence the only way to do it is to map another named domain to your cloud web site
This is probably because browsers like Chrome use the Public Suffix List(https://publicsuffix.org/list/effective_tld_names.dat) to restrict certain cookies. If the domain suffix set on the cookie is shared publicly then the browser may block such a cookie in order to prevent itself from sending "unauthorized" data to other servers running on the same domain.
I have an ASP.NET MVC4 application running on Windows Azure and it uses Azure ACS for Federated Authentication.
When we first started testing the application, it was working in all the browsers except Safari and Opera because of the size of cookie.
I've read several articles online that asked me to use FederatedAuthentication.SessionAuthenticationModule.IsSessionMode = true;
The above statement will store the data in the cookie on the server side. That fixed the problem because only a session identifier is stored on the client(browser).
However, that attribue appears to be removed from the WIF 4.5 api.
Do you know if there is a work around?
Do you save the original token? Do you have something like this in your web.config, or do you set the saveBootstrapTokens config setting to true:
<securityTokenHandlers>
<securityTokenHandlerConfiguration saveBootstrapTokens="true" />
</securityTokenHandlers>
If you do, or if you don't, try setting the saveBootstrapTokens to false! This is will save you a lot of "space".
I had this issue only when I had saveBootstraptokens set to true.
Yes - #astaykov is correct - that's part of it.
As per #Dominick, it's called "IsReferenceMode" in .NET 4.5.
I was using Tomcat 6.0.26 with my project since long time. Now, I need to use EL 2.2 in this project so I moved it to Tomcat 7.0.19 with no other changes (Using Mojarra 2.1.2-b04 with RichFaces 4.0.0). When I start it up, everything is fine until I try any a4j:commandButton or h:commandButton it throw ViewExpiredException even if the application is started for less than a minute (for info, I've forced 30min session timeout in web.xml).
The only thing makes the application works is by changing this setting :
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
It was server and I changed it to client but the server setting is best to keep data server side and don't transfer it to client on each request.
Edit : Looks like the server to client fix the problem of the ViewExpiredException but the user login function on the website doesn't work anymore. It log into the user home, but after any link is clicked, it does the same like the user is not logger (I use a SessionScoped ManagedBean to keep user information).
Anyone have this bug?
Thank you,
Alex.
You will get a ViewExpiredException when the view is not in the session anymore. The described symptoms suggests that the session cookie is not maintained and thus every request has somehow forced the server to create a brand new session.
I can't reproduce your problem locally on a barebones Mojarra 2.1.2 project targeted on Tomcat 7.0.19. The session get maintained perfectly fine. I see the Set-Cookie response header for JSESSIONID on the first request and I see the Cookie request header for JSESSIONID on every subsequent request within the same browser session. That's how it's supposed to work. So the problem is at least not directly related to Mojarra 2.1.2 or Tomcat 7.0.19.
You can use Firebug to see and track the JSESSIONID cookie yourself. That's the first thing I would do. You should check if it's the browser who refuses to send the Cookie request header back (I don't think that this is the case), or that it's the server who sends a new Set-cookie response header everytime (I think that this is the case). If it's indeed the server who re-creates the session everytime even though the browser has sent the Cookie header, then that can only mean that there's an incorrect HttpSession#invalidate() call somewhere in the code base which forces that. Run a debugger to naildown the culprit.