Using Java to Set HttpOnly

Since Java Enterprise Edition 6 (JEE 6), which adopted Java Servlet 3.0technology, it’s programmatically easy to set the HttpOnly flag on acookie.

In fact setHttpOnly and isHttpOnly methods are available in theCookie interface1,and also for session cookies (JSESSIONID)2:

Cookie cookie = getMyCookie('myCookieName');cookie.setHttpOnly(true);

Moreover, since JEE 6 it’s also declaratively easy setting HttpOnlyflag in a session cookie by applying the following configuration in thedeployment descriptor WEB-INF/web.xml:

For Java Enterprise Edition versions prior to JEE 6 a commonworkaround is to overwrite the SET-COOKIE HTTP response headerwith a session cookie value that explicitly appends the HttpOnly flag:

String sessionid = request.getSession().getId();// be careful overwriting: JSESSIONID may have been set with other flagsresponse.setHeader('SET-COOKIE', 'JSESSIONID=' + sessionid + '; HttpOnly');

In this context, overwriting, despite appropriate for the HttpOnlyflag, is discouraged because the JSESSIONID may have been set with otherflags. A better workaround is taking care of the previously set flags orusing the ESAPI#Java_EE library: in factthe addCookie method of the SecurityWrapperResponse3takes care of previously set flags for us. So we could write a servletfilter as the following one:

public void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) throws IOException, ServletException { HttpServletRequest httpServletRequest = (HttpServletRequest) request; HttpServletResponse httpServletResponse = (HttpServletResponse) response; // if errors exist then create a sanitized cookie header and continue SecurityWrapperResponse securityWrapperResponse = new SecurityWrapperResponse(httpServletResponse, 'sanitize'); Cookie[] cookies = httpServletRequest.getCookies(); if (cookies != null) { for (int i = 0; i < cookies.length; i++) { Cookie cookie = cookies[i]; if (cookie != null) { // ESAPI.securityConfiguration().getHttpSessionIdName() returns JSESSIONID by default configuration if (ESAPI.securityConfiguration().getHttpSessionIdName().equals(cookie.getName())) { securityWrapperResponse.addCookie(cookie); } } } } filterChain.doFilter(request, response);}

Some web application servers, that implement JEE 5, and servletcontainers that implement Java Servlet 2.5 (part of JEE 5), also allowcreating HttpOnly session cookies:

• Tomcat 6 In context.xml set the context tag’s attributeuseHttpOnly4as follow:

<?xml version=”1.0” encoding=”UTF-8”?>

Httponly Cookie C#

HTTP cookies can be created in two ways: either in the HTTP layer, on in the application layer in the DOM using JavaScript. And after they are created, some cookies can be accessed from either layer, depending on the application requirements.

HTTP cookies can be created in a web browser either by the Set-Cookie header in a HTTP response or using JavaScript using the document.cookie property. An example from JavaScript console:

The same cookie can be set using a HTTP response header:

This gives application developers great flexibility in customizing the application behavior to match user preferences — for example, if an user indicated a preference to see the website in Russian language, the application can set a cookie language=russian which the browser will send in all subsequent requests. Upon receiving the cookie, the application will then display content in appropriate language, always returning what the user has chosen to see. The cookie can be read from either the HTTP session (Cookie request header), which is what most server-side applications would do, or client-side using JavaScript, a mode preferred by most AJAX JavaScript-based applications.

Httponly Cookies Apache

The problem with the latter access method is that some types of cookies are never intended to be accessed outside of the HTTP channel — for example, session cookies often contain authentication tokens which, if exposed by a malicious JavaScript code, can be used to impersonate the user on the target website.

This would require a vulnerability such as Cross-Site Scripting to be present on the website but ability to hide the authentication cookie from JavaScript code significantly reduces impact of such attack. The httpOnly cookie flag does exactly that — it instructs the browser that this particular cookie should be never exposed to the JavaScript layer and only sent

The flag is defined in RFC 6265 and should be set on all authentication-related cookies that are no intended to be accessed by JavaScript. An example:

Such cookie will be still sent in the Cookie request header, accessible by the server-side web application code, but never exposed to the client-side browser DOM and not accessible from JavaScript.

Cookie Httponly Means

Most web application security scanners will check if session cookies are set with the httpOnly flag and will raise an alert if it's not. Some broken security scanners will raise this alert for any cookies set by the website which is definitely an overkill and a false positive.