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)
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)
Yes, I saw Scott's website and other interesting stuff.
We changed some twitters
(https://twitter.com/Scott_Helme/status/639756303376773120).

On Tue, Oct 20, 2015 at 11:52 AM, Robin Wood <robin (at) digininja (dot) org [email concealed]> wrote:
> 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
> <riramar (at) gmail (dot) com [email concealed]> 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 <robin (at) digininja (dot) org [email concealed]> 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
>>> <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 ]


 

Privacy Statement
Copyright 2010, SecurityFocus