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.

Improve this question

3 Answers 3

Reset to default
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

Improve this answer
2
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.

Improve this answer
2
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.

Improve this answer
3
  • 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, 2010 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, 2010 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, 2010 at 18:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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