Re: hsecscan v0 (https://github.com/riramar/hsecscan)

Have you seen this project by Scott?

https://securityheaders.io/

Similar to yours except works from a website rather than cli.

Robin

On 20 October 2015 at 14:24, Ricardo Iramar dos Santos
<[email protected]> wrote:
> Make sense. I'll include your suggestion in my TODO list.
> My first goal for the version 0 was construct a simple "platform" and
> make it usable.
> One of the goals for version 1 is improve the database with users
> feedback like yours.
> Thanks!
>
> On Tue, Oct 20, 2015 at 10:21 AM, Robin Wood <[email protected]> wrote:
>> 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
>> <[email protected]> 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 <[email protected]> wrote:
>>>> On 19 October 2015 at 16:49, Ricardo Iramar dos Santos
>>>> <[email protected]> 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/presentation/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 <[email protected]> wrote:
>>>>>>
>>>>>> On 18 Oct 2015 03:02, "Ricardo Iramar dos Santos" <[email protected]> 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--ZGRIGTQSZdqhePaWrWlBkwP0DXjt3r4OKLtnaU6ZsrVypT8GqJuN-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-xss-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-internet-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
--------------------------------------