Web Application Security
Re: hsecscan v0 (https://github.com/riramar/hsecscan) Oct 19 2015 03:49PM
Ricardo Iramar dos Santos (riramar gmail com) (1 replies)
Re: hsecscan v0 (https://github.com/riramar/hsecscan) Oct 20 2015 10:24AM
Robin Wood (robin digininja org) (1 replies)
Re: hsecscan v0 (https://github.com/riramar/hsecscan) Oct 20 2015 12:14PM
Ricardo Iramar dos Santos (riramar gmail com) (1 replies)
Re: hsecscan v0 (https://github.com/riramar/hsecscan) Oct 20 2015 12:21PM
Robin Wood (robin digininja org) (1 replies)
I'd say both of those were references not recommendations, the
recommendation should be something along the lines of:

Ensure cookies protecting important data, such as session tokens, are
correctly protected (httponly and secure flags).
Beware session fixation

I may add ensure good entropy on session tokens but that is more in
session management than cookies.

For the security comment, what would you write about cookies in a test
report? Check things like OWASP and see what they say but make sure
whatever you put that it is within the context of the short paragraph
you've got that you give a realistic comment on the header.

Robin

On 20 October 2015 at 13:14, Ricardo Iramar dos Santos
<riramar (at) gmail (dot) com [email concealed]> wrote:
> Thanks for your advise and opinion.
> Have you seen the recommendations field?
> Do you have a suggestion for a better security description?
>
>>> Recommendations: Please at least read these references:
>>> https://tools.ietf.org/html/rfc6265#section-8 and
>>> https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Cookies.
>
> On Tue, Oct 20, 2015 at 8:24 AM, Robin Wood <robin (at) digininja (dot) org [email concealed]> wrote:
>> On 19 October 2015 at 16:49, Ricardo Iramar dos Santos
>> <riramar (at) gmail (dot) com [email concealed]> wrote:
>>> Hi Robin Wood,
>>>
>>> This security description came from here
>>> https://tools.ietf.org/html/rfc6265#section-8 so we could ask your
>>> question to the author.
>>> But IMO the RFC author is saying the HTTPS is insufficient because of
>>> attacks like described here
>>> https://www.usenix.org/conference/usenixsecurity15/technical-sessions/pr
esentation/zheng.
>>> I don't know any other HTTP State Management Mechanism than cookies
>>> for web applications accessible by browsers.
>>
>> I can see what they are trying to say but the snippet you include in
>> the results takes it out of context and doesn't really represent their
>> message. I'd be careful giving results you don't fully understand from
>> your tools, without the context they could cause problems for users
>> who don't do additional research.
>>
>> Robin
>>
>>> On Sun, Oct 18, 2015 at 6:32 AM, Robin Wood <robin (at) digininja (dot) org [email concealed]> wrote:
>>>>
>>>> On 18 Oct 2015 03:02, "Ricardo Iramar dos Santos" <riramar (at) gmail (dot) com [email concealed]> wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> I started to develop in python a dumb tool called hsecscan
>>>>> (https://github.com/riramar/hsecscan). I'll appreciate any feedback.
>>>>> :)
>>>>> It's a security scanner for HTTP response headers. Just finished the
>>>>> usable version 0 with a few features.
>>>>>
>>>>> $ ./hsecscan.py
>>>>> usage: hsecscan.py [-h] [-P] [-p] [-u URL] [-R]
>>>>>
>>>>> A security scanner for HTTP response headers.
>>>>>
>>>>> optional arguments:
>>>>> -h, --help show this help message and exit
>>>>> -P, --database Print the entire response headers database.
>>>>> -p, --headers Print only the enabled response headers from
>>>>> database.
>>>>> -u URL, --URL URL The URL to be scanned.
>>>>> -R, --redirect Print redirect headers.
>>>>>
>>>>>
>>>>> The code itself is short because I spent most of my time constructing
>>>>> the sqlite database. You can check the database content on hsecscan.db
>>>>> (sqlite) or hsecscan.tsv (tab separated value).
>>>>> Most of the headers came from
>>>>> https://www.iana.org/assignments/message-headers/message-headers.xhtml
>>>>> and the security description/reference/recommendation came from the
>>>>> related RFC. I also include all headers from
>>>>> https://www.owasp.org/index.php/List_of_useful_HTTP_headers. The idea
>>>>> is keep the database up-to-date and if you want you can add your
>>>>> headers.
>>>>> Since this is version 0 I didn't include all the features that I want
>>>>> and this is my personal TODO list:
>>>>>
>>>>> Improve output to highlight the required headers
>>>>> Add option to select the method (GET or POST)
>>>>> Improve README.md with more information (eg. how to use as a module)
>>>>> Add options to show only the enabled headers
>>>>> Add option to select the User-Agent header or set any other header
>>>>> Add option to detect bad practice (eg. Content-Type without charset=utf-8)
>>>>>
>>>>>
>>>>> Basically "hsecscan.py -u http://google.com" will do a GET on
>>>>> google.com over HTTP and retrieve all the headers. For each header
>>>>> hsecscan.py will search on the database and print the results. If you
>>>>> select the option "-R" hsecscan.py will also print results for each
>>>>> redirect response header.
>>>>>
>>>>> $ ./hsecscan.py -u http://google.com
>>>>> URL: http://www.google.com.br/?gfe_rd=cr&ei=uO8eVtCNA_Cp8weYqLCgAQ
>>>>> Code: 200
>>>>> Headers:
>>>>> Date: Thu, 15 Oct 2015 00:13:45 GMT
>>>>> Expires: -1
>>>>> Cache-Control: private, max-age=0
>>>>> Content-Type: text/html; charset=ISO-8859-1
>>>>> P3P: CP="This is not a P3P policy! See
>>>>> http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657

>>>>> for more info."
>>>>> Server: gws
>>>>> X-XSS-Protection: 1; mode=block
>>>>> X-Frame-Options: SAMEORIGIN
>>>>> Set-Cookie:
>>>>> PREF=ID=1111111111111111:FF=0:TM=1444868025:LM=1444868025:V=1:S=63__QH8d
-rawj72t;
>>>>> expires=Thu, 31-Dec-2015 16:02:17 GMT; path=/; domain=.google.com.br
>>>>> Set-Cookie:
>>>>> NID=72=CoRBDHqHqS4hFQZX_KM-EihW23odkCZSkndoN2tdH6DJY6lG--ZGRIGTQSZdqhePa
WrWlBkwP0DXjt3r4OKLtnaU6ZsrVypT8GqJuN-9YzcDWHfamVpZTWd0b72YuiGNMDHBRH5X;

>>>>> expires=Fri, 15-Apr-2016 00:13:45 GMT; path=/; domain=.google.com.br;
>>>>> HttpOnly
>>>>> Accept-Ranges: none
>>>>> Vary: Accept-Encoding
>>>>> Connection: close
>>>>>
>>>>>
>>>>> Header Field Name: X-XSS-Protection
>>>>> Type 1: Personal
>>>>> Protocol: http
>>>>> Status:
>>>>> Reference:
>>>>> http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-iv-the-x
ss-filter.aspx
>>>>> Type 2: Response
>>>>> Enable: Y
>>>>> Required: Y
>>>>> HTTPS: N
>>>>> Security Description: This header enables the Cross-site scripting
>>>>> (XSS) filter built into most recent web browsers. It's usually enabled
>>>>> by default anyway, so the role of this header is to re-enable the
>>>>> filter for this particular website if it was disabled by the user.
>>>>> This header is supported in IE 8+, and in Chrome (not sure which
>>>>> versions). The anti-XSS filter was added in Chrome 4. Its unknown if
>>>>> that version honored this header.
>>>>> Security Reference:
>>>>> https://www.owasp.org/index.php/List_of_useful_HTTP_headers
>>>>> Recommendations: Use "X-XSS-Protection: 1; mode=block" whenever is
>>>>> possible (ref.
>>>>> http://blogs.msdn.com/b/ieinternals/archive/2011/01/31/controlling-the-i
nternet-explorer-xss-filter-with-the-x-xss-protection-http-header.aspx).

>>>>> CWE: CWE-79: Improper Neutralization of Input During Web Page
>>>>> Generation ('Cross-site Scripting')
>>>>> CWE URL: https://cwe.mitre.org/data/definitions/79.html
>>>>>
>>>>>
>>>>> Header Field Name: Set-Cookie
>>>>> Type 1: Permanent
>>>>> Protocol: http
>>>>> Status: standard
>>>>> Reference: https://tools.ietf.org/html/rfc6265
>>>>> Type 2: Response
>>>>> Enable: Y
>>>>> Required: N
>>>>> HTTPS: N
>>>>> Security Description: Cookies have a number of security pitfalls. In
>>>>> particular, cookies encourage developers to rely on ambient authority
>>>>> for authentication, often becoming vulnerable to attacks such as
>>>>> cross-site request forgery. Also, when storing session identifiers in
>>>>> cookies, developers often create session fixation vulnerabilities.
>>>>> Transport-layer encryption, such as that employed in HTTPS, is
>>>>> insufficient to prevent a network attacker from obtaining or altering
>>>>> a victim's cookies because the cookie protocol itself has various
>>>>> vulnerabilities. In addition, by default, cookies do not provide
>>>>> confidentiality or integrity from network attackers, even when used in
>>>>> conjunction with HTTPS.
>>>>> Security Reference: https://tools.ietf.org/html/rfc6265#section-8
>>>>> Recommendations: Please at least read these references:
>>>>> https://tools.ietf.org/html/rfc6265#section-8 and
>>>>> https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Cookies.
>>>>> CWE: CWE-614: Sensitive Cookie in HTTPS Session Without 'Secure'
>>>>> Attribute
>>>>> CWE URL: https://cwe.mitre.org/data/definitions/614.html
>>>>
>>>> Hi
>>>> I've not ran the tool yet but this feedback on cookies caught my eye. What
>>>> is ambient authority and why is HTTPS is insufficient to protect a cookie
>>>> from a network attacker?
>>>>
>>>> From this it seems you don't like the idea of cookies being used to manage
>>>> authenticated sessions so what would you suggest as an alternative?
>>>>
>>>> Robin
>>>>
>>>>>
>>>>> Header Field Name: Vary
>>>>> Type 1: Permanent
>>>>> Protocol: http
>>>>> Status: standard
>>>>> Reference: https://tools.ietf.org/html/rfc7231#section-7.1.4
>>>>> Type 2: Response
>>>>> Enable: N
>>>>> Required:
>>>>> HTTPS:
>>>>> Security Description:
>>>>> Security Reference:
>>>>> Recommendations:
>>>>> CWE:
>>>>> CWE URL:
>>>>>
>>>>>
>>>>> Header Field Name: Server
>>>>> Type 1: Permanent
>>>>> Protocol: http
>>>>> Status: standard
>>>>> Reference: https://tools.ietf.org/html/rfc7231#section-7.4.2
>>>>> Type 2: Response
>>>>> Enable: Y
>>>>> Required: N
>>>>> HTTPS: N
>>>>> Security Description: Overly long and detailed Server field values
>>>>> increase response latency and potentially reveal internal
>>>>> implementation details that might make it (slightly) easier for
>>>>> attackers to find and exploit known security holes.
>>>>> Security Reference: https://tools.ietf.org/html/rfc7231#section-7.4.2
>>>>> Recommendations: An origin server SHOULD NOT generate a Server field
>>>>> containing needlessly fine-grained detail and SHOULD limit the
>>>>> addition of subproducts by third parties.
>>>>> CWE: CWE-200: Information Exposure
>>>>> CWE URL: https://cwe.mitre.org/data/definitions/200.html
>>>>>
>>>>>
>>>>> Header Field Name: X-Frame-Options
>>>>> Type 1: Permanent
>>>>> Protocol: http
>>>>> Status: informational
>>>>> Reference: https://tools.ietf.org/html/rfc7034
>>>>> Type 2: Response
>>>>> Enable: Y
>>>>> Required: Y
>>>>> HTTPS: N
>>>>> Security Description: The use of "X-Frame-Options" allows a web page
>>>>> from host B to declare that its content (for example, a button, links,
>>>>> text, etc.) must not be displayed in a frame (<frame> or <iframe>) of
>>>>> another page (e.g., from host A). This is done by a policy declared in
>>>>> the HTTP header and enforced by browser implementations.
>>>>> Security Reference: https://tools.ietf.org/html/rfc7034
>>>>> Recommendations: In 2009 and 2010, many browser vendors
>>>>> ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced
>>>>> the use of a non-standard HTTP [RFC2616] header field
>>>>> "X-Frame-Options" to protect against clickjacking. Please check here
>>>>> https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet
>>>>> what's the best option for your case.
>>>>> CWE: CWE-693: Protection Mechanism Failure
>>>>> CWE URL: https://cwe.mitre.org/data/definitions/693.html
>>>>>
>>>>>
>>>>>
>>>>> This list is sponsored by Cenzic
>>>>> --------------------------------------
>>>>> Let Us Hack You. Before Hackers Do!
>>>>> It's Finally Here - The Cenzic Website HealthCheck. FREE.
>>>>> Request Yours Now!
>>>>> http://www.cenzic.com/2009HClaunch_Securityfocus
>>>>> --------------------------------------
>>>>>

This list is sponsored by Cenzic
--------------------------------------
Let Us Hack You. Before Hackers Do!
It's Finally Here - The Cenzic Website HealthCheck. FREE.
Request Yours Now!
http://www.cenzic.com/2009HClaunch_Securityfocus
--------------------------------------

[ reply ]
Re: hsecscan v0 (https://github.com/riramar/hsecscan) Oct 20 2015 01:24PM
Ricardo Iramar dos Santos (riramar gmail com) (1 replies)
Re: hsecscan v0 (https://github.com/riramar/hsecscan) Oct 20 2015 01:52PM
Robin Wood (robin digininja org) (1 replies)
Re: hsecscan v0 (https://github.com/riramar/hsecscan) Oct 20 2015 03:52PM
Ricardo Iramar dos Santos (riramar gmail com)


 

Privacy Statement
Copyright 2010, SecurityFocus