7

What are the Important fields in HTTP header from security perspective? I tried to google it but unable to find. Can anybody provide me a link to read about it? Thanks in advance.

1

What are the Important fields in HTTP header from security perspective?

When it comes to security, the safest response is to consider everything while placing priority on the things which attackers are known to exploit.

The headers which your server returns on a request are important to attackers (particularly fields which expose the software/version information about your webserver or otherwise allow the attacker to profile the server). (... and +1 for John Conde's mod_header directives on this point - definitely doesn't hurt to tell client browsers to enforce CSRF/XSS policies)

The headers which your webserver and application accept with a request (i.e. anything that your webserver or application has to parse) are important to you because (a) your webserver will probably make an effort to parse all of them - which may provide the attacker a means for executing a buffer overflow or slowloris attack - and (b) your application needs to sanitize and/or validate (as in the case of a cookie which may have been modified) anything used as an input.

  • Cookies can be quite big (up to 1.2MB), but I think slowloris attcks and buffer overflows in headers are more the purview of web server developers. I suppose your application could receive a buffer overflow from parsing header data, but most web languages are high level languages not susceptible to this. That's not to say that PHP or a PHP library itself might not have a buffer overflow vulnerability. But keeping things up to date is all you can really do here. – Lèse majesté Nov 19 '10 at 18:32
  • If you're interested in learning more about buffer overflows as they apply to web apps, read this PDF: adventuresinsecurity.com/Papers/WebAppSecurityBuffOverflows.pdf – Lèse majesté Nov 19 '10 at 18:33
  • 1
    @Lèse majesté - You're absolutely correct - protocol-level exploits are generally directed at the webserver daemon are typically outside the purview of web devs who aren't doing the full-stack thing ... though it certainly couldn't hurt for web devs to have a feel for the "bigger picture" of security - i.e. "this is why you can't trust variables stored in cookies" – danlefree Nov 19 '10 at 18:50
7

Here's some I use:

# Don't allow any pages to be framed by my site or any others
# Defends against Clickjacking!
Header set X-Frame-Options DENY

# Only allow JavaScript from the same domain to be run.
# Also, don't allow inline JavaScript to run. 
Header set X-Content-Security-Policy "allow 'self';"

# Turns on IE 8 XSS prevention tools
Header set X-XSS-Protection "1; mode=block"

# Don't send out the Server header. This way no one knows what 
# version of Apache and PHP I am using
Header unset Server

Useful inks:

https://developer.mozilla.org/en/the_x-frame-options_response_header https://wiki.mozilla.org/Security/CSP/Specification http://www.google.com/support/forum/p/Web%20Search/thread?tid=187e02e745a50a77&hl=en

2

You also want to make sure important cookie headers are sent with the HttpOnly option.

http://www.owasp.org/index.php/HttpOnly

There are ways to force this externally using ModSecurity, apparently, and of course you can (and should) set it from within application code that sets cookies.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.