org.owasp.esapi.filters.SecurityWrapperResponse.createCookieHeader does not respect HttpOnly and Secure properties in ESAPI.properties

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Set HttpUtilities.ForceHttpOnlyCookies=false and 
HttpUtilities.ForceSecureCookies=false in ESAPI.properties
2. Call SecurityWrapperResponse.addCookie()
3. New cookie is created with Secure and HttpOnly set

What is the expected output? What do you see instead?

I would expect the method to respect the values set in ESAPI.properties

Please use labels and text to provide additional information.

The conditionals for using ESAPI.properties are commented out in 
SecurityWrapperResponse: 

    private String createCookieHeader(String name, String value, int maxAge, String domain, String path, boolean secure) {
        // create the special cookie header instead of creating a Java cookie
        // Set-Cookie:<name>=<value>[; <name>=<value>][; expires=<date>][;
        // domain=<domain_name>][; path=<some_path>][; secure][;HttpOnly
        String header = name + "=" + value;
        header += "; Max-Age=" + maxAge;
        if (domain != null) {
            header += "; Domain=" + domain;
        }
        if (path != null) {
            header += "; Path=" + path;
        }
        // if ( secure || ESAPI.securityConfiguration().forceSecureCookies() ) {
        header += "; Secure";
        // }
        // if ( ESAPI.securityConfiguration().forceHttpOnly() ) {
        header += "; HttpOnly";
        // }
        return header;
    }

Original issue reported on code.google.com by augu...@gmail.com on 30 Sep 2010 at 3:25

[GoogleCodeExporter]

Proposed patch attached. 

Better yet would be to use the createCookieHeader() method in 
DefaultHTTPUtilities -These two methods have the exact same source code. 

Unfortunately this is a private method in DefaultHTTPUtilities. Making it 
public and adding it to the HTTPUtilities interface would allow other users to 
re-implement the interface in application specific ways and ensure that they 
are always getting the same behavior as specified in ESAPI.properties.

Are there any negative implications to making this method public and adding it 
to the HTTPUtilities interface? 

Original comment by augu...@gmail.com on 30 Sep 2010 at 3:44

Attachments:

• [Issue 155.diff](https://storage.googleapis.com/google-code-attachments/owasp-esapi-java/issue-155/comment-1/Issue 155.diff)

[GoogleCodeExporter]

Patch committed to SVN. 

Original comment by augu...@gmail.com on 30 Sep 2010 at 8:28

• Changed state: Fixed

[GoogleCodeExporter]

Issue 127 has been merged into this issue.

Original comment by augu...@gmail.com on 19 Oct 2010 at 12:58