WebApp Sec mailing list archives

Previous By Date Next
Previous By Thread Next

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

From: Ricardo Iramar dos Santos <riramar () gmail com>
Date: Tue, 20 Oct 2015 13:52:33 -0200
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 () digininja org> 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 () gmail com> 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 () digininja org> 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 () gmail com> 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 () digininja org> wrote:

On 19 October 2015 at 16:49, Ricardo Iramar dos Santos
<riramar () gmail com> 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 <robin () digininja org> wrote:


On 18 Oct 2015 03:02, "Ricardo Iramar dos Santos" <riramar () gmail com> 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
--------------------------------------
Previous By Date Next
Previous By Thread Next

Current thread: