WebApp Sec mailing list archives
Re: hsecscan v0 (https://github.com/riramar/hsecscan)
From: Ricardo Iramar dos Santos <riramar () gmail com>
Date: Mon, 19 Oct 2015 13:49:23 -0200
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. 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.htmlHi 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? RobinHeader 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 --------------------------------------
Current thread:
- hsecscan v0 (https://github.com/riramar/hsecscan) Ricardo Iramar dos Santos (Oct 17)
- Message not available
- Re: hsecscan v0 (https://github.com/riramar/hsecscan) Ricardo Iramar dos Santos (Oct 19)
- Re: hsecscan v0 (https://github.com/riramar/hsecscan) Robin Wood (Oct 20)
- Re: hsecscan v0 (https://github.com/riramar/hsecscan) Ricardo Iramar dos Santos (Oct 20)
- Re: hsecscan v0 (https://github.com/riramar/hsecscan) Robin Wood (Oct 20)
- Re: hsecscan v0 (https://github.com/riramar/hsecscan) Ricardo Iramar dos Santos (Oct 20)
- Re: hsecscan v0 (https://github.com/riramar/hsecscan) Robin Wood (Oct 20)
- Re: hsecscan v0 (https://github.com/riramar/hsecscan) Ricardo Iramar dos Santos (Oct 20)
- Re: hsecscan v0 (https://github.com/riramar/hsecscan) Ricardo Iramar dos Santos (Oct 19)
- Message not available