https://wiki.owasp.org/api.php?action=feedcontributions&feedformat=atom&user=Dan+Anderson 2026-05-27T05:35:26Z User contributions MediaWiki 1.27.2 https://wiki.owasp.org/index.php?title=Talk:Access_Control_Cheat_Sheet&diff=245702 2018-12-03T06:40:52Z

<p>Dan Anderson: Removed outdated (my) comment</p> <hr /> <div></div>

Dan Anderson https://wiki.owasp.org/index.php?title=Category:Vulnerability_Scanning_Tools&diff=242433 2018-08-10T03:56:07Z

<p>Dan Anderson: Re-alphabetized a bit</p> <hr /> <div>== Description ==<br /> <br /> Web Application Vulnerability Scanners are automated tools that scan web applications, normally from the outside, to look for security vulnerabilities such as [[Cross-site scripting]], [[SQL Injection]], [[Command Injection]], [[Path Traversal]] and insecure server configuration. This category of tools is frequently referred to as [https://www.techopedia.com/definition/30958/dynamic-application-security-testing-dast Dynamic Application Security Testing] (DAST) Tools. A large number of both commercial and open source tools of this type are available and all of these tools have their own strengths and weaknesses. If you are interested in the effectiveness of DAST tools, check out the OWASP [[Benchmark]] project, which is scientifically measuring the effectiveness of all types of vulnerability detection tools, including DAST.<br /> <br /> Here we provide a list of vulnerability scanning tools currently available in the market.<br /> <br /> &lt;br&gt; '''Disclaimer:''' The tools listing in the table below are presented in an alphabetical order. &lt;b&gt;OWASP does not endorse any of the Vendors or Scanning Tools by listing them in the table below. We have made every effort to provide this information as accurately as possible. If you are the vendor of a tool below and think this information is incomplete or incorrect, please send an e-mail to our [mailto:owasp_ha_vulnerability_scanner_project@lists.owasp.org mailing list] and we will make every effort to correct this information.&lt;/b&gt;<br /> <br /> == Tools Listing ==<br /> <br /> {{:Template:OWASP Tool Headings}}<br /> {{OWASP Tool Info || tool_name = [http://www.acunetix.com/ Acunetix WVS] || tool_owner = Acunetix || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = Windows}}<br /> {{OWASP Tool Info || tool_name = [https://www.ibm.com/us-en/marketplace/application-security-on-cloud Application Security on Cloud] || tool_owner = IBM || tool_licence = Commercial || tool_platforms = SaaS}}<br /> {{OWASP Tool Info || tool_name = [http://www-03.ibm.com/software/products/en/appscan-standard AppScan] || tool_owner = IBM || tool_licence = Commercial || tool_platforms = Windows}}<br /> {{OWASP Tool Info || tool_name = [https://www.trustwave.com/Products/Application-Security/App-Scanner-Family/App-Scanner-Enterprise/ App Scanner] || tool_owner = Trustwave || tool_licence = Commercial || tool_platforms = Windows }}<br /> {{OWASP Tool Info || tool_name = [http://www.rapid7.com/products/appspider/ AppSpider] || tool_owner = Rapid7 || tool_licence = Commercial || tool_platforms = Windows}}<br /> {{OWASP Tool Info || tool_name = [https://apptrana.indusface.com/basic/ AppTrana Basic] || tool_owner = AppTrana || tool_licence = Free (Limited Capability) || tool_platforms = SaaS}}<br /> {{OWASP Tool Info || tool_name = [https://www.scanmyserver.com/ AVDS] || tool_owner = Beyond Security || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = SaaS }}<br /> {{OWASP Tool Info || tool_name = [https://www.blueclosure.com BlueClosure BC Detect] || tool_owner = BlueClosure || tool_licence = Commercial, 2 weeks trial || tool_platforms = Most platforms supported}}<br /> {{OWASP Tool Info || tool_name = [http://www.portswigger.net/ Burp Suite] || tool_owner = PortSwiger || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = Most platforms supported }}<br /> {{OWASP Tool Info || tool_name = [https://contrastsecurity.com Contrast] || tool_owner = Contrast Security || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = SaaS or On-Premises }}<br /> {{OWASP Tool Info || tool_name = [https://detectify.com/ Detectify] || tool_owner = Detectify || tool_licence = Commercial || tool_platforms = SaaS }}<br /> {{OWASP Tool Info || tool_name = [http://www.digifort.se/en/scanner Digifort- Inspect] || tool_owner = Digifort|| tool_licence = Commercial || tool_platforms = SaaS }}<br /> {{OWASP Tool Info || tool_name = [https://www.edgescan.com/ edgescan] || tool_owner = edgescan|| tool_licence = Commercial || tool_platforms = SaaS}}<br /> {{OWASP Tool Info || tool_name = [http://www.gamasec.com/Gamascan.aspx GamaScan] || tool_owner = GamaSec || tool_licence = Commercial || tool_platforms = Windows }}<br /> {{OWASP Tool Info || tool_name = [http://rgaucher.info/beta/grabber/ Grabber] || tool_owner = Romain Gaucher || tool_licence = Open Source || tool_platforms = Python 2.4, BeautifulSoup and PyXML}}<br /> {{OWASP Tool Info || tool_name = [https://gravityscan.com/ Gravityscan] || tool_owner = Defiant, Inc. || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = SaaS}}<br /> {{OWASP Tool Info || tool_name = [http://sourceforge.net/p/grendel/code/ci/c59780bfd41bdf34cc13b27bc3ce694fd3cb7456/tree/ Grendel-Scan] || tool_owner = David Byrne || tool_licence = Open Source || tool_platforms = Windows, Linux and Macintosh}}<br /> {{OWASP Tool Info || tool_name = [http://www.golismero.com GoLismero] || tool_owner = GoLismero Team || tool_licence = GPLv2.0 || tool_platforms = Windows, Linux and Macintosh}}<br /> {{OWASP Tool Info || tool_name = [http://www.ikare-monitoring.com/ IKare] || tool_owner = ITrust || tool_licence = Commercial || tool_platforms = N/A }}<br /> {{OWASP Tool Info || tool_name = [https://www.htbridge.com/immuniweb/ ImmuniWeb] || tool_owner = High-Tech Bridge || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = SaaS}}<br /> {{OWASP Tool Info || tool_name = [https://www.indusface.com/index.php/products/web-application-scanning Indusface Web Application Scanning] || tool_owner = Indusface || tool_licence = Commercial || tool_platforms = SaaS}}<br /> {{OWASP Tool Info || tool_name = [http://www.nstalker.com/ N-Stealth] || tool_owner = N-Stalker || tool_licence = Commercial || tool_platforms = Windows}}<br /> {{OWASP Tool Info || tool_name = [https://www.tenable.com/products/tenable-io/web-application-scanning/ Nessus] || tool_owner = Tenable || tool_licence = Commercial || tool_platforms = Windows}}<br /> {{OWASP Tool Info || tool_name = [http://www.mavitunasecurity.com/ Netsparker] || tool_owner = MavitunaSecurity || tool_licence = Commercial || tool_platforms = Windows}}<br /> {{OWASP Tool Info || tool_name = [http://www.rapid7.com/products/nexpose-community-edition.jsp Nexpose] || tool_owner = Rapid7 || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = Windows/Linux}}<br /> {{OWASP Tool Info || tool_name = [http://www.cirt.net/nikto2 Nikto] || tool_owner = CIRT || tool_licence = Open Source|| tool_platforms = Unix/Linux}}<br /> {{OWASP Tool Info || tool_name = [http://www.milescan.com/ ParosPro] || tool_owner = MileSCAN || tool_licence = Commercial || tool_platforms = Windows}}<br /> {{OWASP Tool Info || tool_name = [https://probely.com Probe.ly] || tool_owner = Probe.ly || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = SaaS}}<br /> {{OWASP Tool Info || tool_name = [http://www.websecurify.com/desktop/proxy.html Proxy.app] || tool_owner = Websecurify || tool_licence = Commercial || tool_platforms = Macintosh}}<br /> {{OWASP Tool Info || tool_name = [http://www.qualys.com/products/qg_suite/was/ QualysGuard] || tool_owner = Qualys || tool_licence = Commercial || tool_platforms = N/A}}<br /> {{OWASP Tool Info || tool_name = [http://www.beyondtrust.com/Products/RetinaNetworkSecurityScanner/ Retina] || tool_owner = BeyondTrust || tool_licence = Commercial || tool_platforms = Windows}}<br /> {{OWASP Tool Info || tool_name = [http://www.orvant.com Securus] || tool_owner = Orvant, Inc || tool_licence = Commercial || tool_platforms = N/A}}<br /> {{OWASP Tool Info || tool_name = [http://www.whitehatsec.com/home/services/services.html Sentinel] || tool_owner = WhiteHat Security || tool_licence = Commercial || tool_platforms = N/A}}<br /> {{OWASP Tool Info || tool_name = [http://www.parasoft.com/products/article.jsp?articleId=3169&amp;redname=webtesting&amp;referred=webtesting SOATest] || tool_owner = Parasoft || tool_licence = Commercial || tool_platforms = Windows / Linux / Solaris}}<br /> {{OWASP Tool Info || tool_name = [https://www.tinfoilsecurity.com Tinfoil Security] || tool_owner = Tinfoil Security, Inc. || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = SaaS or On-Premises}}<br /> {{OWASP Tool Info || tool_name = [https://www.trustwave.com/external-vulnerability-scanning.php Trustkeeper Scanner] || tool_owner = Trustwave SpiderLabs || tool_licence = Commercial || tool_platforms = SaaS}}<br /> {{OWASP Tool Info || tool_name = [https://subgraph.com/vega/ Vega] || tool_owner = Subgraph || tool_licence = Open Source || tool_platforms = Windows, Linux and Macintosh}}<br /> {{OWASP Tool Info || tool_name = [http://wapiti.sourceforge.net/ Wapiti] || tool_owner = Informática Gesfor || tool_licence = Open Source || tool_platforms = Windows, Unix/Linux and Macintosh}}<br /> {{OWASP Tool Info || tool_name = [http://www.tripwire.com/it-security-software/enterprise-vulnerability-management/web-application-vulnerability-scanning/ WebApp360] || tool_owner = TripWire || tool_licence = Commercial || tool_platforms = Windows}}<br /> {{OWASP Tool Info || tool_name = [https://webcookies.org WebCookies] || tool_owner = WebCookies || tool_licence = Free|| tool_platforms = SaaS}}<br /> {{OWASP Tool Info || tool_name = [http://www8.hp.com/us/en/software-solutions/software.html?compURI=1341991#.Uuf0KBAo4iw WebInspect] || tool_owner = HP || tool_licence = Commercial || tool_platforms = Windows}}<br /> {{OWASP Tool Info || tool_name = [http://www.websecurify.com/desktop/webreaver.html WebReaver] || tool_owner = Websecurify || tool_licence = Commercial || tool_platforms = Macintosh}}<br /> {{OWASP Tool Info || tool_name = [http://www.german-websecurity.com/en/products/webscanservice/product-details/overview/ WebScanService] || tool_owner = German Web Security || tool_licence = Commercial || tool_platforms = N/A}}<br /> {{OWASP Tool Info || tool_name = [https://suite.websecurify.com/ Websecurify Suite] || tool_owner = Websecurify || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = Windows, Linux, Macintosh}}<br /> {{OWASP Tool Info || tool_name = [http://www.sensepost.com/research/wikto/ Wikto] || tool_owner = Sensepost || tool_licence = Open Source || tool_platforms = Windows}}<br /> {{OWASP Tool Info || tool_name = [http://www.w3af.org/ w3af] || tool_owner = w3af.org || tool_licence = GPLv2.0 || tool_platforms = Linux and Mac}}<br /> {{OWASP Tool Info || tool_name = [https://www.owasp.org/index.php/OWASP_Xenotix_XSS_Exploit_Framework Xenotix XSS Exploit Framework] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Windows}}<br /> {{OWASP Tool Info || tool_name = [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project Zed Attack Proxy] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Windows, Unix/Linux and Macintosh}}<br /> |}<br /> <br /> == References ==<br /> <br /> *[[Source_Code_Analysis_Tools | SAST Tools]] - Similar Information on Static Application Security Testing (SAST) Tools<br /> *http://projects.webappsec.org/Web-Application-Security-Scanner-Evaluation-Criteria<br /> *http://www.slideshare.net/lbsuto/accuracy-and-timecostsofwebappscanners<br /> *http://samate.nist.gov/index.php/Web_Application_Vulnerability_Scanners.html<br /> *http://www.tssci-security.com/archives/2007/11/24/2007-security-testing-tools-in-review/<br /> *http://www.softwareqatest.com/qatweb1.html#SECURITY<br /> <br /> [[Category:OWASP_Tools_Project]]</div>

Dan Anderson https://wiki.owasp.org/index.php?title=Category:Vulnerability_Scanning_Tools&diff=242432 2018-08-10T03:54:08Z

<p>Dan Anderson: Added application security on cloud</p> <hr /> <div>== Description ==<br /> <br /> Web Application Vulnerability Scanners are automated tools that scan web applications, normally from the outside, to look for security vulnerabilities such as [[Cross-site scripting]], [[SQL Injection]], [[Command Injection]], [[Path Traversal]] and insecure server configuration. This category of tools is frequently referred to as [https://www.techopedia.com/definition/30958/dynamic-application-security-testing-dast Dynamic Application Security Testing] (DAST) Tools. A large number of both commercial and open source tools of this type are available and all of these tools have their own strengths and weaknesses. If you are interested in the effectiveness of DAST tools, check out the OWASP [[Benchmark]] project, which is scientifically measuring the effectiveness of all types of vulnerability detection tools, including DAST.<br /> <br /> Here we provide a list of vulnerability scanning tools currently available in the market.<br /> <br /> &lt;br&gt; '''Disclaimer:''' The tools listing in the table below are presented in an alphabetical order. &lt;b&gt;OWASP does not endorse any of the Vendors or Scanning Tools by listing them in the table below. We have made every effort to provide this information as accurately as possible. If you are the vendor of a tool below and think this information is incomplete or incorrect, please send an e-mail to our [mailto:owasp_ha_vulnerability_scanner_project@lists.owasp.org mailing list] and we will make every effort to correct this information.&lt;/b&gt;<br /> <br /> == Tools Listing ==<br /> <br /> {{:Template:OWASP Tool Headings}}<br /> {{OWASP Tool Info || tool_name = [http://www.acunetix.com/ Acunetix WVS] || tool_owner = Acunetix || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = Windows}}<br /> {{OWASP Tool Info || tool_name = [https://www.edgescan.com/ edgescan] || tool_owner = edgescan|| tool_licence = Commercial || tool_platforms = SaaS}}<br /> {{OWASP Tool Info || tool_name = [https://www.ibm.com/us-en/marketplace/application-security-on-cloud Application Security on Cloud] || tool_owner = IBM || tool_licence = Commercial || tool_platforms = SaaS}}<br /> {{OWASP Tool Info || tool_name = [http://www-03.ibm.com/software/products/en/appscan-standard AppScan] || tool_owner = IBM || tool_licence = Commercial || tool_platforms = Windows}}<br /> {{OWASP Tool Info || tool_name = [https://www.trustwave.com/Products/Application-Security/App-Scanner-Family/App-Scanner-Enterprise/ App Scanner] || tool_owner = Trustwave || tool_licence = Commercial || tool_platforms = Windows }}<br /> {{OWASP Tool Info || tool_name = [http://www.rapid7.com/products/appspider/ AppSpider] || tool_owner = Rapid7 || tool_licence = Commercial || tool_platforms = Windows}}<br /> {{OWASP Tool Info || tool_name = [https://apptrana.indusface.com/basic/ AppTrana Basic] || tool_owner = AppTrana || tool_licence = Free (Limited Capability) || tool_platforms = SaaS}}<br /> {{OWASP Tool Info || tool_name = [https://www.scanmyserver.com/ AVDS] || tool_owner = Beyond Security || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = SaaS }}<br /> {{OWASP Tool Info || tool_name = [https://www.blueclosure.com BlueClosure BC Detect] || tool_owner = BlueClosure || tool_licence = Commercial, 2 weeks trial || tool_platforms = Most platforms supported}}<br /> {{OWASP Tool Info || tool_name = [http://www.portswigger.net/ Burp Suite] || tool_owner = PortSwiger || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = Most platforms supported }}<br /> {{OWASP Tool Info || tool_name = [https://contrastsecurity.com Contrast] || tool_owner = Contrast Security || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = SaaS or On-Premises }}<br /> {{OWASP Tool Info || tool_name = [https://detectify.com/ Detectify] || tool_owner = Detectify || tool_licence = Commercial || tool_platforms = SaaS }}<br /> <br /> {{OWASP Tool Info || tool_name = [http://www.digifort.se/en/scanner Digifort- Inspect] || tool_owner = Digifort|| tool_licence = Commercial || tool_platforms = SaaS }}<br /> <br /> {{OWASP Tool Info || tool_name = [http://www.gamasec.com/Gamascan.aspx GamaScan] || tool_owner = GamaSec || tool_licence = Commercial || tool_platforms = Windows }}<br /> {{OWASP Tool Info || tool_name = [http://rgaucher.info/beta/grabber/ Grabber] || tool_owner = Romain Gaucher || tool_licence = Open Source || tool_platforms = Python 2.4, BeautifulSoup and PyXML}}<br /> {{OWASP Tool Info || tool_name = [https://gravityscan.com/ Gravityscan] || tool_owner = Defiant, Inc. || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = SaaS}}<br /> {{OWASP Tool Info || tool_name = [http://sourceforge.net/p/grendel/code/ci/c59780bfd41bdf34cc13b27bc3ce694fd3cb7456/tree/ Grendel-Scan] || tool_owner = David Byrne || tool_licence = Open Source || tool_platforms = Windows, Linux and Macintosh}}<br /> {{OWASP Tool Info || tool_name = [http://www.golismero.com GoLismero] || tool_owner = GoLismero Team || tool_licence = GPLv2.0 || tool_platforms = Windows, Linux and Macintosh}}<br /> {{OWASP Tool Info || tool_name = [http://www.ikare-monitoring.com/ IKare] || tool_owner = ITrust || tool_licence = Commercial || tool_platforms = N/A }}<br /> {{OWASP Tool Info || tool_name = [https://www.htbridge.com/immuniweb/ ImmuniWeb] || tool_owner = High-Tech Bridge || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = SaaS}}<br /> {{OWASP Tool Info || tool_name = [https://www.indusface.com/index.php/products/web-application-scanning Indusface Web Application Scanning] || tool_owner = Indusface || tool_licence = Commercial || tool_platforms = SaaS}}<br /> {{OWASP Tool Info || tool_name = [http://www.nstalker.com/ N-Stealth] || tool_owner = N-Stalker || tool_licence = Commercial || tool_platforms = Windows}}<br /> {{OWASP Tool Info || tool_name = [https://www.tenable.com/products/tenable-io/web-application-scanning/ Nessus] || tool_owner = Tenable || tool_licence = Commercial || tool_platforms = Windows}}<br /> {{OWASP Tool Info || tool_name = [http://www.mavitunasecurity.com/ Netsparker] || tool_owner = MavitunaSecurity || tool_licence = Commercial || tool_platforms = Windows}}<br /> {{OWASP Tool Info || tool_name = [http://www.rapid7.com/products/nexpose-community-edition.jsp Nexpose] || tool_owner = Rapid7 || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = Windows/Linux}}<br /> {{OWASP Tool Info || tool_name = [http://www.cirt.net/nikto2 Nikto] || tool_owner = CIRT || tool_licence = Open Source|| tool_platforms = Unix/Linux}}<br /> {{OWASP Tool Info || tool_name = [http://www.milescan.com/ ParosPro] || tool_owner = MileSCAN || tool_licence = Commercial || tool_platforms = Windows}}<br /> {{OWASP Tool Info || tool_name = [https://probely.com Probe.ly] || tool_owner = Probe.ly || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = SaaS}}<br /> {{OWASP Tool Info || tool_name = [http://www.websecurify.com/desktop/proxy.html Proxy.app] || tool_owner = Websecurify || tool_licence = Commercial || tool_platforms = Macintosh}}<br /> {{OWASP Tool Info || tool_name = [http://www.qualys.com/products/qg_suite/was/ QualysGuard] || tool_owner = Qualys || tool_licence = Commercial || tool_platforms = N/A}}<br /> {{OWASP Tool Info || tool_name = [http://www.beyondtrust.com/Products/RetinaNetworkSecurityScanner/ Retina] || tool_owner = BeyondTrust || tool_licence = Commercial || tool_platforms = Windows}}<br /> {{OWASP Tool Info || tool_name = [http://www.orvant.com Securus] || tool_owner = Orvant, Inc || tool_licence = Commercial || tool_platforms = N/A}}<br /> {{OWASP Tool Info || tool_name = [http://www.whitehatsec.com/home/services/services.html Sentinel] || tool_owner = WhiteHat Security || tool_licence = Commercial || tool_platforms = N/A}}<br /> {{OWASP Tool Info || tool_name = [http://www.parasoft.com/products/article.jsp?articleId=3169&amp;redname=webtesting&amp;referred=webtesting SOATest] || tool_owner = Parasoft || tool_licence = Commercial || tool_platforms = Windows / Linux / Solaris}}<br /> {{OWASP Tool Info || tool_name = [https://www.tinfoilsecurity.com Tinfoil Security] || tool_owner = Tinfoil Security, Inc. || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = SaaS or On-Premises}}<br /> {{OWASP Tool Info || tool_name = [https://www.trustwave.com/external-vulnerability-scanning.php Trustkeeper Scanner] || tool_owner = Trustwave SpiderLabs || tool_licence = Commercial || tool_platforms = SaaS}}<br /> {{OWASP Tool Info || tool_name = [https://subgraph.com/vega/ Vega] || tool_owner = Subgraph || tool_licence = Open Source || tool_platforms = Windows, Linux and Macintosh}}<br /> {{OWASP Tool Info || tool_name = [http://wapiti.sourceforge.net/ Wapiti] || tool_owner = Informática Gesfor || tool_licence = Open Source || tool_platforms = Windows, Unix/Linux and Macintosh}}<br /> {{OWASP Tool Info || tool_name = [http://www.tripwire.com/it-security-software/enterprise-vulnerability-management/web-application-vulnerability-scanning/ WebApp360] || tool_owner = TripWire || tool_licence = Commercial || tool_platforms = Windows}}<br /> {{OWASP Tool Info || tool_name = [https://webcookies.org WebCookies] || tool_owner = WebCookies || tool_licence = Free|| tool_platforms = SaaS}}<br /> {{OWASP Tool Info || tool_name = [http://www8.hp.com/us/en/software-solutions/software.html?compURI=1341991#.Uuf0KBAo4iw WebInspect] || tool_owner = HP || tool_licence = Commercial || tool_platforms = Windows}}<br /> {{OWASP Tool Info || tool_name = [http://www.websecurify.com/desktop/webreaver.html WebReaver] || tool_owner = Websecurify || tool_licence = Commercial || tool_platforms = Macintosh}}<br /> {{OWASP Tool Info || tool_name = [http://www.german-websecurity.com/en/products/webscanservice/product-details/overview/ WebScanService] || tool_owner = German Web Security || tool_licence = Commercial || tool_platforms = N/A}}<br /> {{OWASP Tool Info || tool_name = [https://suite.websecurify.com/ Websecurify Suite] || tool_owner = Websecurify || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = Windows, Linux, Macintosh}}<br /> {{OWASP Tool Info || tool_name = [http://www.sensepost.com/research/wikto/ Wikto] || tool_owner = Sensepost || tool_licence = Open Source || tool_platforms = Windows}}<br /> {{OWASP Tool Info || tool_name = [http://www.w3af.org/ w3af] || tool_owner = w3af.org || tool_licence = GPLv2.0 || tool_platforms = Linux and Mac}}<br /> {{OWASP Tool Info || tool_name = [https://www.owasp.org/index.php/OWASP_Xenotix_XSS_Exploit_Framework Xenotix XSS Exploit Framework] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Windows}}<br /> {{OWASP Tool Info || tool_name = [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project Zed Attack Proxy] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Windows, Unix/Linux and Macintosh}}<br /> |}<br /> <br /> == References ==<br /> <br /> *[[Source_Code_Analysis_Tools | SAST Tools]] - Similar Information on Static Application Security Testing (SAST) Tools<br /> *http://projects.webappsec.org/Web-Application-Security-Scanner-Evaluation-Criteria<br /> *http://www.slideshare.net/lbsuto/accuracy-and-timecostsofwebappscanners<br /> *http://samate.nist.gov/index.php/Web_Application_Vulnerability_Scanners.html<br /> *http://www.tssci-security.com/archives/2007/11/24/2007-security-testing-tools-in-review/<br /> *http://www.softwareqatest.com/qatweb1.html#SECURITY<br /> <br /> [[Category:OWASP_Tools_Project]]</div>

Dan Anderson https://wiki.owasp.org/index.php?title=Source_Code_Analysis_Tools&diff=242431 2018-08-10T03:49:14Z

<p>Dan Anderson: Added ASoC to commercial tools list</p> <hr /> <div>Source code analysis tools, also referred to as Static Application Security Testing (SAST) Tools, are designed to analyze source code and/or compiled versions of code to help find security flaws. <br /> <br /> Some tools are starting to move into the IDE. For the types of problems that can be detected during the software development phase itself, this is a powerful phase within the development life cycle to employ such tools, as it provides immediate feedback to the developer on issues they might be introducing into the code during code development itself. This immediate feedback is very useful, especially when compared to finding vulnerabilities much later in the development cycle.<br /> <br /> == Strengths and Weaknesses ==<br /> <br /> === Strengths ===<br /> <br /> * Scales well -- can be run on lots of software, and can be run repeatedly (as with nightly builds or continuous integration)<br /> * Useful for things that such tools can automatically find with high confidence, such as buffer overflows, SQL Injection Flaws, and so forth<br /> * Output is good for developers -- highlights the precise source files, line numbers, and even subsections of lines that are affected<br /> <br /> === Weaknesses ===<br /> <br /> * Many types of security vulnerabilities are very difficult to find automatically, such as authentication problems, access control issues, insecure use of cryptography, etc. The current state of the art only allows such tools to automatically find a relatively small percentage of application security flaws. However, tools of this type are getting better.<br /> * High numbers of false positives.<br /> * Frequently can't find configuration issues, since they are not represented in the code.<br /> * Difficult to 'prove' that an identified security issue is an actual vulnerability.<br /> * Many of these tools have difficulty analyzing code that can't be compiled. Analysts frequently can't compile code because they don't have the right libraries, all the compilation instructions, all the code, etc.<br /> <br /> ==Important Selection Criteria==<br /> <br /> * Requirement: Must support your programming language, but not usually a key factor once it does.<br /> * Types of vulnerabilities it can detect (out of the [[OWASP Top Ten]]?) (plus more?)<br /> * How accurate is it? False Positive/False Negative rates?<br /> ** Does the tool have an OWASP [[Benchmark]] score?<br /> * Does it understand the libraries/frameworks you use?<br /> * Does it require a fully buildable set of source?<br /> * Can it run against binaries instead of source?<br /> * Can it be integrated into the developer's IDE?<br /> * How hard is it to setup/use?<br /> * Can it be run continuously and automatically?<br /> * License cost for the tool. (Some are sold per user, per org, per app, per line of code analyzed. Consulting licenses are frequently different than end user licenses.)<br /> <br /> ==OWASP Tools Of This Type==<br /> <br /> * [[OWASP SonarQube Project]]<br /> * [http://www.owasp.org/index.php/Category:OWASP_Orizon_Project OWASP Orizon Project]<br /> * [[OWASP_LAPSE_Project | OWASP LAPSE Project]]<br /> * [[OWASP O2 Platform]]<br /> * [[OWASP WAP-Web Application Protection]]<br /> <br /> ==Disclaimer==<br /> <br /> Disclaimer: &lt;b&gt;The tools listed in the tables below are presented in alphabetical order. &lt;i&gt;OWASP does not endorse any of the vendors or tools by listing them in the table below.&lt;/i&gt; We have made every effort to provide this information as accurately as possible. If you are the vendor of a tool below and think that this information is incomplete or incorrect, please send an e-mail to our mailing list and we will make every effort to correct this information.&lt;/b&gt;<br /> <br /> ==Open Source or Free Tools Of This Type==<br /> <br /> * [https://wiki.openstack.org/wiki/Security/Projects/Bandit Bandit] - bandit is a comprehensive source vulnerability scanner for Python<br /> * [http://brakemanscanner.org/ Brakeman] - Brakeman is an open source vulnerability scanner specifically designed for Ruby on Rails applications<br /> * [http://rubygems.org/gems/codesake-dawn Codesake Dawn] - Codesake Dawn is an open source security source code analyzer designed for Sinatra, Padrino for Ruby on Rails applications. It also works on non-web applications written in Ruby<br /> * [http://findbugs.sourceforge.net/ FindBugs] - Find Bugs (including a few security flaws) in Java programs<br /> * [https://find-sec-bugs.github.io/ FindSecBugs] - A security specific plugin for FingBugs that significantly improves FindBug's ability to find security vulnerabilities in Java programs<br /> * [http://www.dwheeler.com/flawfinder/ Flawfinder] Flawfinder - Scans C and C++<br /> * [https://www.bishopfox.com/resources/tools/google-hacking-diggity/attack-tools/ Google CodeSearchDiggity] - Uses Google Code Search to identifies vulnerabilities in open source code projects hosted by Google Code, MS CodePlex, SourceForge, Github, and more. The tool comes with over 130 default searches that identify SQL injection, cross-site scripting (XSS), insecure remote and local file includes, hard-coded passwords, and much more. ''Essentially, Google CodeSearchDiggity provides a source code security analysis of nearly every single open source code project in existence – simultaneously.''<br /> * [https://github.com/wireghoul/graudit/ Graudit] - Scans multiple languages for various security flaws. <br /> * [http://pmd.sourceforge.net/ PMD] - PMD scans Java source code and looks for potential code problems (this is a code quality tool that does not focus on security issues)<br /> * [https://github.com/designsecurity/progpilot Progpilot] - Progpilot is a static analyzer tool for PHP that detects security vulnerabilities such as XSS and SQL Injection.<br /> * [http://msdn.microsoft.com/en-us/library/ms933794.aspx PreFast] (Microsoft) - PREfast is a static analysis tool that identifies defects in C/C++ programs. Last update 2006.<br /> * [https://pumascan.com/ Puma Scan] - Puma Scan is a .NET C# open source static source code analyzer that runs as an IDE plugin for Visual Studio and via MSBuild in CI pipelines.<br /> * [https://dotnet-security-guard.github.io/ .NET Security Guard] - Roslyn analyzers that aim to help security audits on .NET applications. It will find SQL injections, LDAP injections, XXE, cryptography weakness, XSS and more.<br /> * [http://rips-scanner.sourceforge.net/ RIPS] - RIPS is a static source code analyzer for vulnerabilities in PHP web applications. Please see notes on the sourceforge.net site.<br /> * [https://github.com/FloeDesignTechnologies/phpcs-security-audit phpcs-security-audit] - phpcs-security-audit is a set of PHP_CodeSniffer rules that finds flaws or weaknesses related to security in PHP and its popular CMS or frameworks. It currently has core PHP rules as well as Drupal 7 specific rules.<br /> * [http://www.sonarqube.org/ SonarQube] - Scans source code for more than 20 languages for Bugs, Vulnerabilities, and Code Smells. SonarQube IDE plugins for Eclipse, Visual Studio, and IntelliJ provided by [http://www.sonarlint.org/ SonarLint].<br /> * [http://sourceforge.net/projects/visualcodegrepp/ VisualCodeGrepper (VCG)] - Scans C/C++, C#, VB, PHP, Java, and PL/SQL for security issues and for comments which may indicate defective code. The config files can be used to carry out additional checks for banned functions or functions which commonly cause security issues.<br /> * [http://www.xanitizer.net Xanitizer] - Scans Java for security vulnerabilities, mainly via taint analysis. The tool comes with a number of predefined vulnerability detectors which can additionally be extended by the user. It's free for academic and open source projects (see [https://www.rigs-it.com/xanitizer-pricing/]).<br /> <br /> ==Commercial Tools Of This Type==<br /> * [https://www.ptsecurity.com/ww-en/products/ai/ Application Inspector (Positive Technologies)] - combines SAST, DAST, IAST, SCA, configuration analysis and other technologies, incl. unique abstract interpretation for high accuracy rate with minimum false positives; has a unique capability to generate special test queries (exploits) to verify detected vulnerabilities during SAST analysis; integrates with CI/CD, VCS, etc. Supported languages are Java, C#, PHP, JavaScript, Objective C, VB.Net, PL/SQL, T-SQL, and others. <br /> * [https://www.ibm.com/us-en/marketplace/application-security-on-cloud Application Security on Cloud] (IBM) - Provides SAST, DAST and mobile security testing as well as OpenSource vulnerability detection as a cloud delivered service. <br /> * [http://www-01.ibm.com/software/rational/products/appscan/source/ AppScan Source] (IBM)<br /> * [http://www.blueclosure.com BlueClosure BC Detect] (BlueClosure)<br /> * [https://buguroo.com/products/bugblast-next-gen-appsec-platform/bugscout-sca bugScout] (Buguroo Offensive Security) Latest generation source code analysis tool bugScout detects source code vulnerabilities and makes possible an accurate management of the life cycles due to its easy use.<br /> * [http://www.castsoftware.com/solutions/application-security/cwe#SupportedSecurityStandards CAST AIP] (CAST) Performs static and architectural analysis to check for: SQL Injection, Cross Site Scripting (XSS), Input Validation,  Insecure Cryptographic Storage, Information Leakage and Improper Error Handling, Data Access, API Abuse, Encapsulation on over 30 languages.<br /> * [https://www.codacy.com/ Codacy] is free for open source projects, and integrates with tools such as Brakeman, Bandit, FindBugs, and a number of others. It offers security patterns for languages such as Python, Ruby, Scala, Java, Javascript and more.<br /> * [http://www.contrastsecurity.com/ Contrast from Contrast Security] Contrast performs code security without actually doing static analysis. Contrast does Interactive Application Security Testing (IAST), correlating runtime code &amp; data analysis. It provides code level results without actually relying on static analysis.<br /> * [http://www.coverity.com/products/code-advisor/ Coverity Code Advisor] (Synopsys)<br /> * [https://www.checkmarx.com/technology/static-code-analysis-sca/ CxSAST] (Checkmarx)<br /> * [http://www8.hp.com/us/en/software-solutions/static-code-analysis-sast/ Fortify] (HP)<br /> * [http://www.juliasoft.com/solutions Julia] - SaaS Java static analysis (JuliaSoft)<br /> * [http://www.klocwork.com/capabilities/static-code-analysis KlocWork] (KlocWork)<br /> * [https://www.kiuwan.com/code-analysis/ Kiuwan] - SaaS Software Quality &amp; Security Analysis (an [http://www.optimyth.com Optimyth] company)<br /> * [http://www.parasoft.com/jsp/capabilities/static_analysis.jsp?itemId=547 Parasoft Test] (Parasoft)<br /> * [https://pitss.com/products/pitss-con/ PITSS.CON] (PITTS)<br /> * [http://www.viva64.com/en/ PVS-Studio] (PVS-Studio) For C/C++, C#<br /> * [https://pumascanpro.com/ Puma Scan Professional] - Puma Scan Professional is a .NET C# static source code analyzer that runs as an IDE plugin for Visual Studio and via MSBuild in CI pipelines.<br /> * [https://www.ripstech.com/ RIPS Code Analysis] (RIPS Technologies) - RIPS is a SAST solution specialized for PHP that detects unknown security vulnerabilities and code quality issues. It can be easily integrated into the SDLC and supports various industry standards.<br /> * [https://www.synopsys.com/software-integrity/resources/datasheets/secureassist.html SecureAssist] (Synopsys) - Prevent insecure coding and configurations (Java, .NET, PHP, and JavaScript) by scanning code automatically as an IDE plugin for Eclipse, IntelliJ, and Visual Studio etc. The guidance for fixing insecure coding contains references to OWASP resources.<br /> * [https://www.whitehatsec.com/products/static-application-security-testing/ Sentinel Source] (Whitehat)<br /> * [https://www.synopsys.com/software-integrity/products/interactive-application-security-testing.html Seeker] (Synopsys) Seeker performs code security without actually doing static analysis. Seeker does Interactive Application Security Testing (IAST), correlating runtime code &amp; data analysis with simulated attacks. It provides code level results without actually relying on static analysis.<br /> * [http://www.sourcepatrol.co.uk/ Source Patrol] (Pentest)<br /> * [http://www.veracode.com/products/binary-static-analysis-sast Veracode Static Analysis] (Veracode)<br /> * [http://www.xanitizer.net Xanitizer] - Scans Java for security vulnerabilities, mainly via taint analysis.<br /> <br /> ==More info==<br /> <br /> * [[Appendix_A:_Testing_Tools | Appendix A: Testing Tools]]<br /> * [http://samate.nist.gov/index.php/Source_Code_Security_Analyzers.html NIST's list of Source Code Security Analysis Tools]<br /> * [[:Category:Vulnerability_Scanning_Tools | DAST Tools]] - Similar info on Dynamic Application Security Testing (DAST) Tools<br /> <br /> [[Category:OWASP .NET Project]]<br /> [[Category:SAMM-CR-2]]<br /> __NOTOC__</div>

Dan Anderson https://wiki.owasp.org/index.php?title=Talk:Proposal_for_2015-09-25_OWASP_Board_Meeting&diff=201312 2015-09-29T22:43:23Z

<p>Dan Anderson: My input</p> <hr /> <div>Discussion<br /> <br /> ----<br /> <br /> I think this is a good idea. Although, perhaps #3 and #10 should include some communications with the group in advance. See if they want money. See if they need help with a budget, etc. --[[User:Dan Anderson|Dan Anderson]] ([[User talk:Dan Anderson|talk]]) 17:43, 29 September 2015 (CDT)</div>

Dan Anderson https://wiki.owasp.org/index.php?title=User:Dan_Anderson&diff=184215 2014-10-28T19:36:04Z

<p>Dan Anderson: </p> <hr /> <div>CISSP, CISA, Sun Certified Solaris Admin 8 &amp; 10, IBM Certified Specialist - Rational AppScan Standard Edition, NSA IAM/IEM :D<br /> <br /> I've worked in IT security on and off since 1991 in the USAF and with several civilian companies. I am currently (since 2005) a security consultant with a multi-national.<br /> <br /> My contributions: [[Special:Contributions/Dan_Anderson]]</div>

Dan Anderson https://wiki.owasp.org/index.php?title=Talk:Transport_Layer_Protection_Cheat_Sheet&diff=184214 2014-10-28T19:34:01Z

<p>Dan Anderson: </p> <hr /> <div>Make the warning about &quot;no such thing as internal network&quot; more prominent. There are several types of attacks that can be conducted by using ARP spoofing and MitM an SSL/TLS session. One of the most interesting is hijacking credentials to virtual machine provisioning interfaces, then reusing the credentials to create malicious VMs, boot existing VMs off of untrusted media, etc. I think this is an overlooked issue with SSL since most of the focus is on ecommerce.<br /> <br /> Second, add a paragraph regarding the BEAST attack and mitigations present in later version of the TLS spec. Urge adoption of modern TLS implementations.<br /> <br /> == Rule - Do Not Provide Non-TLS Pages for Secure Content ==<br /> <br /> Currently this rule states: ''&quot;All pages which are available over TLS must not be available over a non-TLS connection. A user may inadvertently bookmark or manually type a URL to a HTTP page (e.g. http://example.com/myaccount) within the authenticated portion of the application. If this request is processed by the application then the response, and any sensitive data, would be returned to the user over the clear text HTTP.&quot;''<br /> <br /> Wouldn't it be more precise to state that secure '''data''' shouldn't be availabe over non-TLS connections ? Pages still can be available over non-TLS connections, and pose no risk when they provide non-secure data.<br /> It's up to the application to provide secure data only when the connection is properly secured.<br /> --[[User:Peter Mosmans|Peter Mosmans]] 01:16, 14 May 2013 (UTC)<br /> <br /> I added a rule about the SHA-1 deprecation issue today. It's a temporary issue with limited duration value (a couple years), but IMO, if someone comes to us asking about the proper way to set up SSL/TLS - I think we should tell them about the issue. Feel free to edit/expand as you see fit. Thanks! Dan<br /> --[[User:Dan Anderson|Dan Anderson]] ([[User talk:Dan Anderson|talk]]) 14:34, 28 October 2014 (CDT)</div>

Dan Anderson https://wiki.owasp.org/index.php?title=Transport_Layer_Protection_Cheat_Sheet&diff=184213 2014-10-28T19:31:49Z

<p>Dan Anderson: /* Server Certificate and Protocol Configuration */</p> <hr /> <div> __NOTOC__<br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:Cheatsheets-header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' <br /> = Introduction =<br /> __TOC__{{TOC hidden}}<br /> <br /> This cheat sheet provides a simple model to follow when implementing transport layer protection for an application. Although the concept of SSL is known to many, the actual details and security specific decisions of implementation are often poorly understood and frequently result in insecure deployments. This article establishes clear rules which provide guidance on securely designing and configuring transport layer security for an application. This article is focused on the use of SSL/TLS between a web application and a web browser, but we also encourage the use of SSL/TLS or other network encryption technologies, such as VPN, on back end and other non-browser based connections.&lt;br&gt; <br /> <br /> == Architectural Decision ==<br /> <br /> An architectural decision must be made to determine the appropriate method to protect data when it is being transmitted. The most common options available to corporations are Virtual Private Networks (VPN) or a SSL/TLS model commonly used by web applications. The selected model is determined by the business needs of the particular organization. For example, a VPN connection may be the best design for a partnership between two companies that includes mutual access to a shared server over a variety of protocols. Conversely, an Internet facing enterprise web application would likely be best served by a SSL/TLS model. <br /> <br /> This cheat sheet will focus on security considerations when the SSL/TLS model is selected. This is a frequently used model for publicly accessible web applications.<br /> <br /> = Providing Transport Layer Protection with SSL/TLS =<br /> <br /> == Benefits ==<br /> <br /> The primary benefit of transport layer security is the protection of web application data from unauthorized disclosure and modification when it is transmitted between clients (web browsers) and the web application server, and between the web application server and back end and other non-browser based enterprise components. <br /> <br /> The server validation component of TLS provides authentication of the server to the client. If configured to require client side certificates, TLS can also play a role in client authentication to the server. However, in practice client side certificates are not often used in lieu of username and password based authentication models for clients.<br /> <br /> TLS also provides two additional benefits that are commonly overlooked; integrity guarantees and replay prevention. A TLS stream of communication contains built-in controls to prevent tampering with any portion of the encrypted data. In addition, controls are also built-in to prevent a captured stream of TLS data from being replayed at a later time.<br /> <br /> It should be noted that TLS provides the above guarantees to data during transmission. TLS does not offer any of these security benefits to data that is at rest. Therefore appropriate security controls must be added to protect data while at rest within the application or within data stores.<br /> <br /> == Basic Requirements ==<br /> <br /> The basic requirements for using TLS are: access to a Public Key Infrastructure (PKI) in order to obtain certificates, access to a directory or an Online Certificate Status Protocol (OCSP) responder in order to check certificate revocation status, and agreement/ability to support a minimum configuration of protocol versions and protocol options for each version.<br /> <br /> == SSL vs. TLS ==<br /> <br /> The terms, Secure Socket Layer (SSL) and Transport Layer Security (TLS) are often used interchangeably. In fact, SSL v3.1 is equivalent to TLS v1.0. However, different versions of SSL and TLS are supported by modern web browsers and by most modern web frameworks and platforms. For the purposes of this cheat sheet we will refer to the technology generically as TLS. Recommendations regarding the use of SSL and TLS protocols, as well as browser support for TLS, can be found in the rule below titled [[Transport_Layer_Protection_Cheat_Sheet#Rule_-_Only_Support_Strong_Protocols| &quot;Only Support Strong Protocols&quot;]].<br /> <br /> [[Image:Asvs_cryptomodule.gif|thumb|350px|right|Cryptomodule Parts and Operation]]<br /> <br /> == When to Use a FIPS 140-2 Validated Cryptomodule ==<br /> <br /> If the web application may be the target of determined attackers (a common threat model for Internet accessible applications handling sensitive data), it is strongly advised to use TLS services that are provided by [http://csrc.nist.gov/groups/STM/cmvp/validation.html FIPS 140-2 validated cryptomodules]. <br /> <br /> A cryptomodule, whether it is a software library or a hardware device, basically consists of three parts:<br /> <br /> * Components that implement cryptographic algorithms (symmetric and asymmetric algorithms, hash algorithms, random number generator algorithms, and message authentication code algorithms) <br /> * Components that call and manage cryptographic functions (inputs and outputs include cryptographic keys and so-called critical security parameters) <br /> * A physical container around the components that implement cryptographic algorithms and the components that call and manage cryptographic functions<br /> <br /> The security of a cryptomodule and its services (and the web applications that call the cryptomodule) depend on the correct implementation and integration of each of these three parts. In addition, the cryptomodule must be used and accessed securely. The includes consideration for:<br /> <br /> * Calling and managing cryptographic functions<br /> * Securely Handling inputs and output<br /> * Ensuring the secure construction of the physical container around the components<br /> <br /> In order to leverage the benefits of TLS it is important to use a TLS service (e.g. library, web framework, web application server) which has been FIPS 140-2 validated. In addition, the cryptomodule must be installed, configured and operated in either an approved or an allowed mode to provide a high degree of certainty that the FIPS 140-2 validated cryptomodule is providing the expected security services in the expected manner.<br /> <br /> If the system is legally required to use FIPS 140-2 encryption (e.g., owned or operated by or on behalf of the U.S. Government) then TLS must be used and SSL disabled. Details on why SSL is unacceptable are described in Section 7.1 of [http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program].<br /> <br /> Further reading on the use of TLS to protect highly sensitive data against determined attackers can be viewed in [http://csrc.nist.gov/publications/nistpubs/800-52/SP800-52.pdf SP800-52 Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations]<br /> <br /> == Secure Server Design ==<br /> <br /> === Rule - Use TLS for All Login Pages and All Authenticated Pages ===<br /> <br /> The login page and all subsequent authenticated pages must be exclusively accessed over TLS. The initial login page, referred to as the &quot;login landing page&quot;, must be served over TLS. Failure to utilize TLS for the login landing page allows an attacker to modify the login form action, causing the user's credentials to be posted to an arbitrary location. Failure to utilize TLS for authenticated pages after the login enables an attacker to view the unencrypted session ID and compromise the user's authenticated session. <br /> <br /> === Rule - Use TLS on Any Networks (External and Internal) Transmitting Sensitive Data ===<br /> <br /> All networks, both external and internal, which transmit sensitive data must utilize TLS or an equivalent transport layer security mechanism. It is not sufficient to claim that access to the internal network is &quot;restricted to employees&quot;. Numerous recent data compromises have shown that the internal network can be breached by attackers. In these attacks, sniffers have been installed to access unencrypted sensitive data sent on the internal network. <br /> <br /> === Rule - Do Not Provide Non-TLS Pages for Secure Content ===<br /> <br /> All pages which are available over TLS must not be available over a non-TLS connection. A user may inadvertently bookmark or manually type a URL to a HTTP page (e.g. http://example.com/myaccount) within the authenticated portion of the application. If this request is processed by the application then the response, and any sensitive data, would be returned to the user over the clear text HTTP.<br /> <br /> === Rule - REMOVED - Do Not Perform Redirects from Non-TLS Page to TLS Login Page ===<br /> <br /> This recommendation has been removed. Ultimately, the below guidance will only provide user education and cannot provide any technical controls to protect the user against a man-in-the-middle attack. <br /> <br /> --<br /> <br /> A common practice is to redirect users that have requested a non-TLS version of the login page to the TLS version (e.g. http://example.com/login redirects to https://example.com/login). This practice creates an additional attack vector for a man in the middle attack. In addition, redirecting from non-TLS versions to the TLS version reinforces to the user that the practice of requesting the non-TLS page is acceptable and secure.<br /> <br /> In this scenario, the man-in-the-middle attack is used by the attacker to intercept the non-TLS to TLS redirect message. The attacker then injects the HTML of the actual login page and changes the form to post over unencrypted HTTP. This allows the attacker to view the user's credentials as they are transmitted in the clear.<br /> <br /> It is recommended to display a security warning message to the user whenever the non-TLS login page is requested. This security warning should urge the user to always type &quot;HTTPS&quot; into the browser or bookmark the secure login page. This approach will help educate users on the correct and most secure method of accessing the application.<br /> <br /> Currently there are no controls that an application can enforce to entirely mitigate this risk. Ultimately, this issue is the responsibility of the user since the application cannot prevent the user from initially typing [http://owasp.org http://example.com/login] (versus HTTPS). <br /> <br /> Note: [http://www.w3.org/Security/wiki/Strict_Transport_Security Strict Transport Security] will address this issue and will provide a server side control to instruct supporting browsers that the site should only be accessed over HTTPS<br /> <br /> === Rule - Do Not Mix TLS and Non-TLS Content ===<br /> <br /> A page that is available over TLS must be comprised completely of content which is transmitted over TLS. The page must not contain any content that is transmitted over unencrypted HTTP. This includes content from unrelated third party sites. <br /> <br /> An attacker could intercept any of the data transmitted over the unencrypted HTTP and inject malicious content into the user's page. This malicious content would be included in the page even if the overall page is served over TLS. In addition, an attacker could steal the user's session cookie that is transmitted with any non-TLS requests. This is possible if the cookie's 'secure' flag is not set. See the rule 'Use &quot;Secure&quot; Cookie Flag'<br /> <br /> === Rule - Use &quot;Secure&quot; Cookie Flag ===<br /> <br /> The &quot;Secure&quot; flag must be set for all user cookies. Failure to use the &quot;secure&quot; flag enables an attacker to access the session cookie by tricking the user's browser into submitting a request to an unencrypted page on the site. This attack is possible even if the server is not configured to offer HTTP content since the attacker is monitoring the requests and does not care if the server responds with a 404 or doesn't respond at all.<br /> <br /> === Rule - Keep Sensitive Data Out of the URL ===<br /> <br /> Sensitive data must not be transmitted via URL arguments. A more appropriate place is to store sensitive data in a server side repository or within the user's session. When using TLS the URL arguments and values are encrypted during transit. However, there are two methods that the URL arguments and values could be exposed.<br /> <br /> 1. The entire URL is cached within the local user's browser history. This may expose sensitive data to any other user of the workstation.<br /> <br /> 2. The entire URL is exposed if the user clicks on a link to another HTTPS site. This may expose sensitive data within the referral field to the third party site. This exposure occurs in most browsers and will only occur on transitions between two TLS sites. <br /> <br /> For example, a user following a link on [http://owasp.org https://example.com] which leads to [http://owasp.org https://someOtherexample.com] would expose the full URL of [http://owasp.org https://example.com] (including URL arguments) in the referral header (within most browsers). This would not be the case if the user followed a link on [http://owasp.org https://example.com] to [http://owasp.org http://someHTTPexample.com]<br /> <br /> === Rule - Prevent Caching of Sensitive Data ===<br /> <br /> The TLS protocol provides confidentiality only for data in transit but it does not help with potential data leakage issues at the client or intermediary proxies. As a result, it is frequently prudent to instruct these nodes not to cache or persist sensitive data. One option is to add anticaching headers to relevant HTTP responses, (for example, &quot;Cache-Control: no-cache, no-store&quot; and &quot;Expires: 0&quot; for coverage of many modern browsers as of 2013). For compatibility with HTTP/1.0 (i.e., when user agents are really old or the webserver works around quirks by forcing HTTP/1.0) the response should also include the header &quot;Pragma: no-cache&quot;. More information is available in [http://www.ietf.org/rfc/rfc2616.txt HTTP 1.1 RFC 2616], section 14.9.<br /> <br /> === Rule - Use HTTP Strict Transport Security ===<br /> <br /> A new browser security setting called HTTP Strict Transport Security (HSTS) will significantly enhance the implementation of TLS for a domain. HSTS is enabled via a special response header and this instructs [https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#Browser_Support compatible browsers] to enforce the following security controls:<br /> <br /> * All requests to the domain will be sent over HTTPS<br /> * Any attempts to send an HTTP requests to the domain will be automatically upgraded by the browser to HTTPS before the request is sent<br /> * If a user encounters a bad SSL certificate, the user will receive an error message and will not be allowed to override the warning message<br /> <br /> Additional information on HSTS can be found at [https://www.owasp.org/index.php/HTTP_Strict_Transport_Security https://www.owasp.org/index.php/HTTP_Strict_Transport_Security] and also on the OWASP [http://www.youtube.com/watch?v=zEV3HOuM_Vw&amp;feature=youtube_gdata AppSecTutorial Series - Episode 4]<br /> <br /> === Rule - Prefer Ephemeral Key Exchanges ===<br /> <br /> Ephemeral key exchanges are based on Diffie-Hellman and use per-session, temporary keys during the initial SSL/TLS handshake. They provide perfect forward secrecy (PFS), which means a compromise of the server's long term signing key does not compromise the confidentiality of past session. When the server uses an ephemeral key, the server will sign the temporary key with its long term key (the long term key is the customary key available in its certificate).<br /> <br /> Use cryptographic parameters (like DH-parameter) that use a secure length that match to the supported keylength of your certificate (&gt;=2048 bits or equivalent Elliptic Curves). As some middleware had some issues with this, upgrade to the latest version.<br /> <br /> If you have a server farm and are providing forward secrecy, then you might have to disable session resumption. For example, Apache writes the session id's and master secrets to disk so all servers in the farm can participate in resuming a session (there is currently no in-memory mechanism to achieve the sharing). Writing the session id and master secret to disk undermines forward secrecy.<br /> <br /> == Server Certificate and Protocol Configuration ==<br /> <br /> Note: If using a FIPS 140-2 cryptomodule disregard the following rules and defer to the recommended configuration for the particular cryptomodule.<br /> <br /> === Rule - Be aware of and have a plan for the SHA-1 deprecation plan ===<br /> <br /> In order to avoid presenting end users with progressive certificate warnings, organizations must proactively address the browser vendor's upcoming SHA-1 deprecation plans. The Google Chrome plan is probably the most specific and aggressive at this point: [http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html Gradually sunsetting SHA-1]<br /> <br /> If your organization has no [https://support.globalsign.com/customer/portal/articles/1499561-sha-256-compatibility SHA256 compatibility issues] then it may be appropriate to move your site to a SHA256 signed certificate/chain. If there are, or may be, issues - you should ensure that your SHA-1 certificates expire before 1/1/2017. <br /> <br /> === Rule - Use an Appropriate Certification Authority for the Application's User Base ===<br /> <br /> An application user must never be presented with a warning that the certificate was signed by an unknown or untrusted authority. The application's user population must have access to the public certificate of the certification authority which issued the server's certificate. For Internet accessible websites, the most effective method of achieving this goal is to purchase the TLS certificate from a recognize certification authority. Popular Internet browsers already contain the public certificates of these recognized certification authorities. <br /> <br /> Internal applications with a limited user population can use an internal certification authority provided its public certificate is securely distributed to all users. However, remember that all certificates issued by this certification authority will be trusted by the users. Therefore, utilize controls to protect the private key and ensure that only authorized individuals have the ability to sign certificates. <br /> <br /> The use of self signed certificates is never acceptable. Self signed certificates negate the benefit of end-point authentication and also significantly decrease the ability for an individual to detect a man-in-the-middle attack. <br /> <br /> === Rule - Only Support Strong Protocols ===<br /> <br /> SSL/TLS is a collection of protocols. Weaknesses have been identified with earlier SSL protocols, including [http://www.schneier.com/paper-ssl-revised.pdf SSLv2] and [http://www.yaksman.org/~lweith/ssl.pdf SSLv3]. The best practice for transport layer protection is to only provide support for the TLS protocols - TLS1.0, TLS 1.1 and TLS 1.2. This configuration will provide maximum protection against skilled and determined attackers and is appropriate for applications handling sensitive data or performing critical operations.<br /> <br /> [http://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers Nearly all modern browsers support at least TLS 1.0]. As of February 2013, contemporary browsers (Chrome v20+, IE v8+, Opera v10+, and Safari v5+) [http://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers support TLS 1.1 and TLS 1.2]. You should provide support for TLS 1.1 and TLS 1.2 to accommodate clients which support the protocols. The client and server (usually) negotiate the best protocol, that is supported on both sides.<br /> <br /> TLS 1.0 is still widely used as 'best' protocol by a lot of browsers, that are not patched to the very latest version. It suffers [http://www.yassl.com/yaSSL/Blog/Entries/2010/10/7_Differences_between_SSL_and_TLS_Protocol_Versions.html CBC Chaining attacks and Padding Oracle attacks]. TLSv1.0 should only be used only after risk analysis and acceptance.<br /> <br /> Under no circumstances neither SSLv2 nor SSLv3 should be enabled as a protocol selection:<br /> * The [http://www.schneier.com/paper-ssl-revised.pdf SSLv2 protocol is broken] and does not provide adequate transport layer protection.<br /> * [http://www.yaksman.org/~lweith/ssl.pdf SSLv3 had been known for weaknesses] which severely compromise the channel's security long before the [https://www.openssl.org/~bodo/ssl-poodle.pdf 'POODLE'-Bug] finally stopped to tolerate this protocol by October 2014. Switching off SSLv3 terminates the support of legacy browsers like [https://www.ssllabs.com/ssltest/viewClient.html?name=IE&amp;version=6&amp;platform=XP IE6/XP] and elder.<br /> <br /> === Rule - Only Support Strong Cryptographic Ciphers ===<br /> <br /> Each protocol (SSLv3, TLSv1.0, etc) provides cipher suites. As of TLS 1.2, [http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-3 there is support for over 300 suites (320+ and counting)], including [http://www.mail-archive.com/cryptography@randombit.net/msg03785.html national vanity cipher suites]. The strength of the encryption used within a TLS session is determined by the encryption cipher negotiated between the server and the browser. In order to ensure that only strong cryptographic ciphers are selected the server must be modified to disable the use of weak ciphers and to configure the ciphers in an adequate order. It is recommended to configure the server to only support strong ciphers and to use sufficiently large key sizes. In general, the following should be observed when selecting CipherSuites:<br /> * Use the very latest recommendations, they may be volantile these days<br /> * Setup your Policy to get a Whitelist for recommended Ciphers, e.g.:<br /> ** Activate to set the Cipher Order by the Server<br /> ** Highest Priority for Ciphers that support 'Forward Secrecy' (-&gt; Support ephemeral Diffie-Hellman key exchange) [http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html]<br /> ** Favor DHE over ECDHE (and monitor the CPU usage, see Notes below), ECDHE lacks now of really reliable Elliptic Curves, see discussion about secp{224,256,384,521}r1 and secp256k1, cf. [http://safecurves.cr.yp.to], [https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929]. The solution might be to use [http://www.researchgate.net/profile/Johannes_Merkle/publication/260050106_Standardisierung_der_Brainpool-Kurven_fr_TLS_und_IPSec/file/60b7d52f36a0cc2fdd.pdf Brainpool Curves &lt;nowiki&gt;[German]&lt;/nowiki&gt;], defined for TLS in [http://tools.ietf.org/html/rfc7027 RFC 7027], or [http://eprint.iacr.org/2007/286 Edwards Curves]. The most promising candidate for the latter is [https://tools.ietf.org/html/draft-josefsson-tls-curve25519-05 'Curve25519'], that is not yet defined for TLS, cf. [http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 IANA] &lt;!--- as at June 2014 ---&gt;<br /> ** Use RSA-Keys (no DSA/DSS: they get very weak, if a bad entropy source is used during signing, cf. [https://projectbullrun.org/dual-ec/tls.html], [https://factorable.net/weakkeys12.conference.pdf]) &lt;!--- as at June 2014 ---&gt;<br /> ** Favor GCM over CBC regardless of the cipher size<br /> ** Watch also for Stream Ciphers which XOR the key stream with plaintext (such as AES/CTR mode) &lt;!--- Jim please check this ---&gt;<br /> ** Priorize the ciphers by the sizes of the Cipher and the MAC<br /> ** Use SHA1 or above for digests, prefer SHA2 (or equivalent)<br /> ** Disable weak ciphers (which is implicitly done by this whitelist) without disabling latency browsers and bots that have to be supported (find the best compromise), actually the cipher TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) does this job.<br /> *** Disable cipher suites that do not offer authentication (NULL ciphersuites, aNULL or eNULL)<br /> *** Disable anonymous Diffie-Hellman key exchange (ADH)<br /> *** Disable export level ciphers (EXP, eg. ciphers containing DES)<br /> *** Disable key sizes smaller than 128 bits for encrypting payload traffic (see [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2_pdf.html BSI: TR-02102 Part 2 (German)])<br /> *** Disable the use of MD5 as a hashing mechanism for payload traffic<br /> *** Disable the use of IDEA Cipher Suites (see [http://tools.ietf.org/html/rfc5469])<br /> *** Disable RC4 cipher suites (see [http://www.isg.rhul.ac.uk/tls/])<br /> ** Ciphers should be usable for DH-Pamameters &gt;= 2048 bits, without blocking latency browsers (The cipher ‘DHE-RSA-AES128-SHA’ is suppressed as some browsers like to use it but are not capable to cope with DH-Params &gt; 1024 bits.)<br /> * Define a Cipher String that works with different Versions of your encryption tool, like openssl<br /> * Verify your cipher string<br /> ** with an audit-tool, like [[O-Saft|OWASP 'O-Saft' (OWASP SSL audit for testers / OWASP SSL advanced forensic tool)]]<br /> ** listing it manually with your encryption software, e.g. openssl ciphers -v &lt;cipher-string&gt; (the result may differ by version), e.g.:<br /> {{Top_10_2010:ExampleBeginTemplate|year=2013}} <br /> openssl ciphers -v &quot;EDH+aRSA+AESGCM:EDH+aRSA+AES:DHE-RSA-AES256-SHA:EECDH+aRSA+AESGCM:EECDH+aRSA+AES:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:RSA+AESGCM:RSA+AES+SHA:DES-CBC3-SHA:-DHE-RSA-AES128-SHA&quot; &lt;br&gt;<br /> &lt;nowiki&gt;#&lt;/nowiki&gt;add optionally ':!aNULL:!eNULL:!LOW:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:!ADH:!IDEA' to protect older Versions of OpenSSL&lt;br&gt;<br /> &lt;nowiki&gt;#&lt;/nowiki&gt;you may use openssl ciphers -V &quot;...&quot; for openssl &gt;= 1.0.1:<br /> &lt;small&gt;<br /> 0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD<br /> 0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD<br /> 0x00,0x6B - DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256<br /> 0x00,0x39 - DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1<br /> 0x00,0x67 - DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256<br /> 0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD<br /> 0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD<br /> 0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384<br /> 0xC0,0x14 - ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1<br /> 0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256<br /> 0xC0,0x13 - ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1<br /> 0x00,0x9D - AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD<br /> 0x00,0x9C - AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD<br /> 0x00,0x35 - AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1<br /> 0x00,0x2F - AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1<br /> 0x00,0x0A - DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1<br /> &lt;/small&gt;<br /> {{Top_10_2010:ExampleEndTemplate}}<br /> <br /> * Inform yourself how to securely configure the settings for your used services or hardware, e.g. [https://bettercrypto.org BetterCrypto.org: Applied Crypto Hardening (DRAFT)]<br /> * Check new software and hardware versions for new security settings.<br /> <br /> &lt;b&gt;Notes:&lt;/b&gt;<br /> * According to my researches the most common browsers should be supported with this setting, too (see also [https://www.ssllabs.com/ssltest/index.html SSL Labs: SSL Server Test -&gt; SSL Report -&gt; Handshake Simulation]).<br /> * Monitor the performance of your server, e.g. the TLS handshake with DHE hinders the CPU abt 2.4 times more than ECDHE, cf. [http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html#some-benchmarks Vincent Bernat, 2011], [http://nmav.gnutls.org/2011/12/price-to-pay-for-perfect-forward.html nmav's Blog, 2011].<br /> * Use of Ephemeral Diffie-Hellman key exchange will protect confidentiality of the transmitted plaintext data even if the corresponding RSA or DSS server private key got compromised. An attacker would have to perform active man-in-the-middle attack at the time of the key exchange to be able to extract the transmitted plaintext. All modern browsers support this key exchange with the notable exception of Internet Explorer prior to Windows Vista.<br /> <br /> Additional information can be obtained within the [http://www.ietf.org/rfc/rfc5246.txt TLS 1.2 RFC 5246], [https://www.ssllabs.com/projects/best-practices/index.html SSL Labs: 'SSL/TLS Deployment Best Practices'], [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2_pdf.html BSI: 'TR-02102 Part 2 (German)'], [http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report ENISA: 'Algorithms, Key Sizes and Parameters Report'] and [http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf FIPS 140-2 IG]. <br /> <br /> === Rule - Support TLS-PSK and TLS-SRP for Mutual Authentication ===<br /> <br /> When using a shared secret or password offer TLS-PSK (Pre-Shared Key) or TLS-SRP (Secure Remote Password), which are known as Password Authenticated Key Exchange (PAKEs). TLS-PSK and TLS-SRP properly bind the channel, which refers to the cryptographic binding between the outer tunnel and the inner authentication protocol. IANA currently reserves [http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-3 79 PSK cipehr suites] and [http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-3 9 SRP cipher suites].<br /> <br /> Basic authentication places the user's password on the wire in the plain text after a server authenticates itself. Basic authentication only provides unilateral authentication. In contrast, both TLS-PSK and TLS-SRP provide mutual authentication, meaning each party proves it knows the password without placing the password on the wire in the plain text.<br /> <br /> Finally, using a PAKE removes the need to trust an outside party, such as a Certification Authority (CA).<br /> <br /> === Rule - Only Support Secure Renegotiations ===<br /> <br /> A design weakness in TLS, identified as [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3555 CVE-2009-3555], allows an attacker to inject a plaintext of his choice into a TLS session of a victim. In the HTTPS context the attacker might be able to inject his own HTTP requests on behalf of the victim. The issue can be mitigated either by disabling support for TLS renegotiations or by supporting only renegotiations compliant with [http://www.ietf.org/rfc/rfc5746.txt RFC 5746]. All modern browsers have been updated to comply with this RFC.<br /> <br /> === Rule - Disable Compression ===<br /> <br /> Compression Ratio Info-leak Made Easy (CRIME) is an exploit against the data compression scheme used by the TLS and SPDY protocols. The exploit allows an adversary to recover user authentication cookies from HTTPS. The recovered cookie can be subsequently used for session hijacking attacks.<br /> <br /> === Rule - Use Strong Keys &amp; Protect Them ===<br /> <br /> The private key used to generate the cipher key must be sufficiently strong for the anticipated lifetime of the private key and corresponding certificate. The current best practice is to select a key size of at least 2048 bits. Additional information on key lifetimes and comparable key strengths can be found in [http://www.keylength.com/en/compare/], [http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf NIST SP 800-57]. In addition, the private key must be stored in a location that is protected from unauthorized access.<br /> <br /> === Rule - Use a Certificate That Supports Required Domain Names ===<br /> <br /> A user should never be presented with a certificate error, including prompts to reconcile domain or hostname mismatches, or expired certificates. If the application is available at both [https://owasp.org https://www.example.com] and [https://owasp.org https://example.com] then an appropriate certificate, or certificates, must be presented to accommodate the situation. The presence of certificate errors desensitizes users to TLS error messages and increases the possibility an attacker could launch a convincing phishing or man-in-the-middle attack.<br /> <br /> For example, consider a web application accessible at [https://owasp.org https://abc.example.com] and [https://owasp.org https://xyz.example.com]. One certificate should be acquired for the host or server ''abc.example.com''; and a second certificate for host or server ''xyz.example.com''. In both cases, the hostname would be present in the Subject's Common Name (CN).<br /> <br /> Alternatively, the Subject Alternate Names (SANs) can be used to provide a specific listing of multiple names where the certificate is valid. In the example above, the certificate could list the Subject's CN as ''example.com'', and list two SANs: ''abc.example.com'' and ''xyz.example.com''. These certificates are sometimes referred to as &quot;multiple domain certificates&quot;.<br /> <br /> === Rule - Use Fully Qualified Names in Certificates ===<br /> <br /> Use fully qualified names in the DNS name field, and do not use unqualifed names (e.g., 'www'), local names (e.g., 'localhost'), or private IP addresses (e.g., 192.168.1.1) in the DNS name field. Unqualifed names, local names, or private IP addresses violate the certificate specification.<br /> <br /> === Rule - Do Not Use Wildcard Certificates ===<br /> <br /> You should refrain from using wildcard certificates. Though they are expedient at circumventing annoying user prompts, they also [[Least_privilege|violate the principal of least privilege]] and asks the user to trust all machines, including developer's machines, the secretary's machine in the lobby and the sign-in kiosk. Obtaining access to the private key is left as an exercise for the attacker, but its made much easier when stored on the file system unprotected.<br /> <br /> Statistics gathered by Qualys for [http://media.blackhat.com/bh-us-10/presentations/Ristic/BlackHat-USA-2010-Ristic-Qualys-SSL-Survey-HTTP-Rating-Guide-slides.pdf Internet SSL Survey 2010] indicate wildcard certificates have a 4.4% share, so the practice is not standard for public facing hosts. Finally, wildcard certificates violate [https://www.cabforum.org/EV_Certificate_Guidelines.pdf EV Certificate Guidelines].<br /> <br /> === Rule - Do Not Use RFC 1918 Addresses in Certificates ===<br /> <br /> Certificates should not use private addresses. RFC 1918 is [http://tools.ietf.org/rfc/rfc1918.txt Address Allocation for Private Internets]. Private addresses are Internet Assigned Numbers Authority (IANA) reserved and include 192.168/16, 172.16/12, and 10/8.<br /> <br /> Certificates issued with private addresses violate [https://www.cabforum.org/EV_Certificate_Guidelines.pdf EV Certificate Guidelines]. In addition, Peter Gutmann writes in in [http://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf Engineering Security]: &quot;This one is particularly troublesome because, in combination with the router-compromise attacks... and ...OSCP-defeating measures, it allows an attacker to spoof any EV-certificate site.&quot;<br /> <br /> === Rule - Always Provide All Needed Certificates ===<br /> <br /> Clients attempt to solve the problem of identifying a server or host using PKI and X509 certificate. When a user receives a server or host's certificate, the certificate must be validated back to a trusted root certification authority. This is known as path validation.<br /> <br /> There can be one or more intermediate certificates in between the end-entity (server or host) certificate and root certificate. In addition to validating both endpoints, the user will also have to validate all intermediate certificates. Validating all intermediate certificates can be tricky because the user may not have them locally. This is a well-known PKI issue called the “Which Directory?&quot; problem.<br /> <br /> To avoid the “Which Directory?&quot; problem, a server should provide the user with all required certificates used in a path validation.<br /> <br /> == Test your overall TLS/SSL setup and your Certificate ==<br /> <br /> * [[Testing_for_SSL-TLS_%28OWASP-CM-001%29 | OWASP Testing Guide: Chapter on SSL/TLS Testing]]<br /> * [[O-Saft|OWASP 'O-Saft' (OWASP SSL audit for testers / OWASP SSL advanced forensic tool)]]<br /> * [https://www.ssllabs.com/ssltest SSL LABS Server Test]<br /> * other Tools: [[Testing_for_Weak_SSL/TSL_Ciphers,_Insufficient_Transport_Layer_Protection_%28OWASP-EN-002%29#References| Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002) (DRAFT)]] - References - Tools<br /> <br /> == Client (Browser) Configuration ==<br /> <br /> The validation procedures to ensure that a certificate is valid are complex and difficult to correctly perform. In a typical web application model, these checks will be performed by the client's web browser in accordance with local browser settings and are out of the control of the application. However, these items do need to be addressed in the following scenarios:<br /> <br /> * The application server establishes connections to other applications over TLS for purposes such as web services or any exchange of data<br /> * A thick client application is connecting to a server via TLS<br /> <br /> In these situations extensive certificate validation checks must occur in order to establish the validity of the certificate. Consult the following resources to assist in the design and testing of this functionality. The NIST PKI testing site includes a full test suite of certificates and expected outcomes of the test cases.<br /> * [http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html NIST PKI Testing]<br /> * [http://www.ietf.org/rfc/rfc5280.txt IETF RFC 5280]<br /> <br /> As specified in the above guidance, if the certificate can not be validated for any reason then the connection between the client and server must be dropped. Any data exchanged over a connection where the certificate has not properly been validated could be exposed to unauthorized access or modification.<br /> <br /> == Additional Controls ==<br /> <br /> === Extended Validation Certificates ===<br /> <br /> Extended validation certificates (EV Certificates) proffer an enhanced investigation by the issuer into the requesting party due to the industry's race to the bottom. The purpose of EV certificates is to provide the user with greater assurance that the owner of the certificate is a verified legal entity for the site. Browsers with support for EV certificates distinguish an EV certificate in a variety of ways. Internet Explorer will color a portion of the URL in green, while Mozilla will add a green portion to the left of the URL indicating the company name. <br /> <br /> High value websites should consider the use of EV certificates to enhance customer confidence in the certificate. It should also be noted that EV certificates do not provide any greater technical security for the TLS. The purpose of the EV certificate is to increase user confidence that the target site is indeed who it claims to be.<br /> <br /> === Client-Side Certificates ===<br /> <br /> Client side certificates can be used with TLS to prove the identity of the client to the server. Referred to as &quot;two-way TLS&quot;, this configuration requires the client to provide their certificate to the server, in addition to the server providing their's to the client. If client certificates are used, ensure that the same validation of the client certificate is performed by the server, as indicated for the validation of server certificates above. In addition, the server should be configured to drop the TLS connection if the client certificate cannot be verified or is not provided. <br /> <br /> The use of client side certificates is relatively rare currently due to the complexities of certificate generation, safe distribution, client side configuration, certificate revocation and reissuance, and the fact that clients can only authenticate on machines where their client side certificate is installed. Such certificates are typically used for very high value connections that have small user populations.<br /> <br /> === Certificate and Public Key Pinning ===<br /> <br /> Hybrid and native applications can take advantage of [[Certificate_and_Public_Key_Pinning|certificate and public key pinning]]. Pinning associates a host (for example, server) with an identity (for example, certificate or public key), and allows an application to leverage knowledge of the pre-existing relationship. At runtime, the application would inspect the certificate or public key received after connecting to the server. If the certificate or public key is expected, then the application would proceed as normal. If unexpected, the application would stop using the channel and close the connection since an adversary could control the channel or server.<br /> <br /> Pinning still requires customary X509 checks, such as revocation, since CRLs and OCSP provides real time status information. Otherwise, an application could possibly (1) accept a known bad certificate; or (2) require an out-of-band update, which could result in a lengthy App Store approval.<br /> <br /> Browser based applications are at a disadvantage since most browsers do not allow the user to leverage pre-existing relationships and ''a priori'' knowledge. In addition, Javascript and Websockets do not expose methods to for a web app to query the underlying secure connection information (such as the certificate or public key). It is noteworthy that Chromium based browsers perform pinning on selected sites, but the list is currently maintained by the vendor.<br /> <br /> For more information, please see the [[Pinning Cheat Sheet]].<br /> <br /> = Providing Transport Layer Protection for Back End and Other Connections =<br /> <br /> Although not the focus of this cheat sheet, it should be stressed that transport layer protection is necessary for back-end connections and any other connection where sensitive data is exchanged or where user identity is established. Failure to implement an effective and robust transport layer security will expose sensitive data and undermine the effectiveness of any authentication or access control mechanism. <br /> <br /> == Secure Internal Network Fallacy ==<br /> <br /> The internal network of a corporation is not immune to attacks. Many recent high profile intrusions, where thousands of sensitive customer records were compromised, have been perpetrated by attackers that have gained internal network access and then used sniffers to capture unencrypted data as it traversed the internal network.<br /> <br /> = Related Articles =<br /> <br /> * OWASP – [[Testing for SSL-TLS (OWASP-CM-001)|Testing for SSL-TLS]], and OWASP [[Guide to Cryptography]] <br /> * OWASP – [http://www.owasp.org/index.php/ASVS Application Security Verification Standard (ASVS) – Communication Security Verification Requirements (V10)]<br /> * OWASP – ASVS Article on [[Why you need to use a FIPS 140-2 validated cryptomodule]]<br /> * SSL Labs – [https://www.ssllabs.com/projects/best-practices/index.html SSL/TLS Deployment Best Practices]<br /> * SSL Labs – [http://www.ssllabs.com/projects/rating-guide/index.html SSL Server Rating Guide]<br /> * ENISA – [http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report Algorithms, Key Sizes and Parameters Report]<br /> * BSI – [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2_pdf.html BSI TR-02102 Part 2 (German)]<br /> * yaSSL – [http://www.yassl.com/yaSSL/Blog/Entries/2010/10/7_Differences_between_SSL_and_TLS_Protocol_Versions.html Differences between SSL and TLS Protocol Versions]<br /> * NIST – [http://csrc.nist.gov/publications/nistpubs/800-52/SP800-52.pdf SP 800-52 Guidelines for the selection and use of transport layer security (TLS) Implementations]<br /> * NIST – [http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf FIPS 140-2 Security Requirements for Cryptographic Modules]<br /> * NIST – [http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program]<br /> * NIST - [http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf NIST SP 800-57 Recommendation for Key Management, Revision 3], [http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-57-Part%203-Rev.1 Public DRAFT]<br /> * NIST – [http://csrc.nist.gov/publications/drafts.html#sp800-95 SP 800-95 Guide to Secure Web Services] <br /> * IETF – [http://www.ietf.org/rfc/rfc5280.txt RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile]<br /> * IETF – [http://www.ietf.org/rfc/rfc2246.txt RFC 2246 The Transport Layer Security (TLS) Protocol Version 1.0 (JAN 1999)]<br /> * IETF – [http://www.ietf.org/rfc/rfc4346.txt RFC 4346 The Transport Layer Security (TLS) Protocol Version 1.1 (APR 2006)]<br /> * IETF – [http://www.ietf.org/rfc/rfc5246.txt RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 (AUG 2008)]<br /> * bettercrypto - [https://bettercrypto.org Applied Crypto Hardening: HOWTO for secure crypto settings of the most common services (DRAFT)]<br /> <br /> = Authors and Primary Editors =<br /> <br /> Michael Coates - michael.coates[at]owasp.org &lt;br/&gt;<br /> Dave Wichers - dave.wichers[at]owasp.org &lt;br/&gt;<br /> Michael Boberski - boberski_michael[at]bah.com&lt;br/&gt;<br /> Tyler Reguly -treguly[at]sslfail.com<br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == Other Cheatsheets ==<br /> <br /> {{Cheatsheet_Navigation_Body}}<br /> <br /> |}<br /> <br /> [[Category:Cheatsheets]]</div>

Dan Anderson https://wiki.owasp.org/index.php?title=List_of_useful_HTTP_headers&diff=172404 2014-04-11T05:20:47Z

<p>Dan Anderson: </p> <hr /> <div>This page lists useful security-related HTTP headers. In most architectures these headers can be set in web server configuration ([http://httpd.apache.org/docs/2.0/mod/mod_headers.html Apache], [http://technet.microsoft.com/pl-pl/library/cc753133(v=ws.10).aspx IIS]), without changing actual application's code. This offers significantly faster and cheaper method for at least partial mitigation of existing issues, and an additional layer of defense for new applications.<br /> <br /> {| border=&quot;1&quot;<br /> |-<br /> ! Header name<br /> ! Description<br /> ! Example<br /> |-<br /> |[http://tools.ietf.org/html/rfc6797 Strict-Transport-Security]<br /> |HTTP Strict-Transport-Security (HSTS) enforces secure (HTTP over SSL/TLS) connections to the server. This reduces impact of bugs in web applications leaking session data through cookies and external links and defends against Man-in-the-middle attacks. HSTS also disables the ability for user's to ignore SSL negotiation warnings.<br /> |&lt;code&gt;Strict-Transport-Security: max-age=16070400; includeSubDomains&lt;/code&gt;<br /> |-<br /> | [http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01 X-Frame-Options], [http://tools.ietf.org/html/draft-ietf-websec-frame-options-00 Frame-Options]<br /> | Provides [[Clickjacking]] protection. Values: ''deny'' - no rendering within a frame, ''sameorigin'' - no rendering if origin mismatch, ''allow-from: DOMAIN'' - allow rendering if framed by frame loaded from ''DOMAIN''<br /> | &lt;code&gt; X-Frame-Options: deny&lt;/code&gt;<br /> |-<br /> | [http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx X-XSS-Protection]<br /> | 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.<br /> | &lt;code&gt;X-XSS-Protection: 1; mode=block&lt;/code&gt;<br /> |-<br /> | [http://blogs.msdn.com/b/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx X-Content-Type-Options]<br /> | The only defined value, &quot;nosniff&quot;, prevents Internet Explorer and Google Chrome from MIME-sniffing a response away from the declared content-type. This also applies to [http://code.google.com/chrome/extensions/hosting.html Google Chrome], when downloading extensions. This reduces exposure to drive-by download attacks and sites serving user uploaded content that, by clever naming, could be treated by MSIE as executable or dynamic HTML files.<br /> | &lt;code&gt; X-Content-Type-Options: nosniff &lt;/code&gt;<br /> |-<br /> |[http://www.w3.org/TR/CSP/ Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP]<br /> |[[Content Security Policy]] requires careful tuning and precise definition of the policy. If enabled, CSP has significant impact on the way browser renders pages (e.g., inline JavaScript disabled by default and must be explicitly allowed in policy). CSP prevents a wide range of attacks, including [[Cross-site scripting]] and other cross-site injections.<br /> |&lt;code&gt;Content-Security-Policy: default-src 'self'&lt;/code&gt;<br /> |-<br /> | [http://www.w3.org/TR/CSP/ Content-Security-Policy-Report-Only]<br /> | Like Content-Security-Policy, but only reports. Useful during implementation, tuning and testing efforts.<br /> | &lt;code&gt;Content-Security-Policy-Report-Only: default-src 'self'; report-uri http://loghost.example.com/reports.jsp&lt;/code&gt;<br /> |}<br /> <br /> <br /> ==Check Your Headers==<br /> <br /> Visit Check Your Headers to view and evaluate any website's security headers. http://cyh.herokuapp.com/cyh<br /> <br /> For Chrome, the Recx Security Analyser extension checks a number of security relevant headers and gives a nice report on the findings.<br /> [https://chrome.google.com/webstore/detail/recx-security-analyser/ljafjhbjenhgcgnikniijchkngljgjda Recx Security Analyser]<br /> <br /> <br /> ==Real life examples==<br /> Below examples present selected HTTP headers as set by popular websites to demonstrate that they are indeed being used in production services:<br /> <br /> ===Facebook===<br /> As of January 2013 [https://www.facebook.com/ Facebook] main page was setting these security related HTTP headers. <br /> <br /> '''Strict-Transport-Security:''' max-age=60<br /> '''X-Content-Type-Options:''' nosniff<br /> '''X-Frame-Options:''' DENY<br /> '''X-WebKit-CSP:''' &lt;small&gt;default-src *; script-src https://*.facebook.com<br /> http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net<br /> *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:*<br /> 'unsafe-inline' 'unsafe-eval' https://*.akamaihd.net http://*.akamaihd.net;<br /> style-src * 'unsafe-inline'; connect-src https://*.facebook.com http://*.facebook.com<br /> https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.spotilocal.com:*<br /> https://*.akamaihd.net ws://*.facebook.com:* http://*.akamaihd.net;&lt;/small&gt;<br /> '''X-XSS-Protection:''' 1; mode=block<br /> <br /> Especially interesting is Facebook's use of [http://www.w3.org/TR/CSP/ Content Security Policy] (using Google Chrome syntax), whose implementation can be [http://www.html5rocks.com/en/tutorials/security/content-security-policy/ challenging] for large sites with heavy usage of JavaScript.<br /> <br /> ===Google+===<br /> As of January 2013 [https://plus.google.com/ Google+] main page was setting these security related HTTP headers:<br /> <br /> '''x-content-type-options:''' nosniff<br /> '''x-frame-options:''' SAMEORIGIN<br /> '''x-xss-protection:''' 1; mode=block<br /> <br /> ===Twitter===<br /> As of May 2013 [https://twitter.com/ Twitter] main page was setting these security related HTTP headers:<br /> <br /> '''strict-transport-security:''' max-age=631138519<br /> '''x-frame-options:''' SAMEORIGIN<br /> '''x-xss-protection:''' 1; mode=block</div>

Dan Anderson https://wiki.owasp.org/index.php?title=Source_Code_Analysis_Tools&diff=133892 2012-08-05T06:49:12Z

<p>Dan Anderson: IBM is listed as a member on the member page - grouped with other member products.</p> <hr /> <div>Source Code Analysis tools are designed to analyze source code and/or compiled version of code in order to help find security flaws. Ideally, such tools would automatically find security flaws with a high degree of confidence that what is found is indeed a flaw. However, this is beyond the state of the art for many types of application security flaws. Thus, such tools frequently serve as aids for an analyst to help them zero in on security relevant portions of code so they can find flaws more efficiently, rather than a tool that simply finds flaws automatically.<br /> <br /> Some tools are starting to move into the IDE. For the types of problems that can be detected during the software development phase itself, this is a powerful phase within the development lifecycle to employ such tools, as it provides immediate feedback to the developer on issues they might be introducing into the code during code development itself. This immediate feedback is very useful as compared to finding vulnerabilities much later in the development cycle.<br /> <br /> ==Strengths and Weaknesses of such tools==<br /> <br /> === Strengths ===<br /> * Scales Well (Can be run on lots of software, and can be repeatedly (like in nightly builds))<br /> * For things that such tools can automatically find with high confidence, such as buffer overflows, SQL Injection Flaws, etc. they are great.<br /> <br /> === Weaknesses ===<br /> * Many types of security vulnerabilities are very difficult to find automatically, such as authentication problems, access control issues, insecure use of cryptography, etc. The current state of the art only allows such tools to automatically find a relatively small percentage of application security flaws. Tools of this type are getting better, however.<br /> * High numbers of false positives.<br /> * Frequently can't find configuration issues, since they are not represented in the code.<br /> * Difficult to 'prove' that an identified security issue is an actual vulnerability.<br /> * Many of these tools have difficulty analyzing code that can't be compiled. Analysts frequently can't compile code because they don't have the right libraries, all the compilation instructions, all the code, etc.<br /> <br /> ==Important Selection Criteria==<br /> <br /> * Requirement: Must support your language, but not usually a key factor once it does.<br /> <br /> * Types of Vulnerabilities it can detect (Out of the OWASP Top Ten?) (plus more?)<br /> * Does it require a fully buildable set of source?<br /> * Can it run against binaries instead of source?<br /> * Can it be integrated into the developer's IDE?<br /> * License cost for the tool. (Some are sold per user, per org, per app, per line of code analyzed. Consulting licenses are frequently different than end user licenses.)<br /> <br /> ==OWASP Tools Of This Type==<br /> * [http://www.owasp.org/index.php/Category:OWASP_Orizon_Project OWASP Orizon Project]<br /> * [[OWASP_LAPSE_Project | OWASP LAPSE Project]]<br /> * [[OWASP O2 Platform]]<br /> <br /> ==Open Source or Free Tools Of This Type==<br /> <br /> * [http://www.stachliu.com/resources/tools/google-hacking-diggity-project/attack-tools/ Google CodeSearchDiggity] - Utilizes Google Code Search to identifies vulnerabilities in open source code projects hosted by Google Code, MS CodePlex, SourceForge, Github, and more. The tool comes with over 130 default searches that identify SQL injection, cross-site scripting (XSS), insecure remote and local file includes, hard-coded passwords, and much more. ''Essentially, Google CodeSearchDiggity provides a source code security analysis of nearly every single open source code project in existence – simultaneously.'' <br /> * [http://findbugs.sourceforge.net/ FindBugs] - Find Bugs (including some security flaws) in Java Programs<br /> * [http://msdn.microsoft.com/en-us/library/bb429476(VS.80).aspx FxCop] (Microsoft) - FxCop is an application that analyzes managed code assemblies (code that targets the .NET Framework common language runtime) and reports information about the assemblies, such as possible design, localization, performance, and security improvements.<br /> * [http://pmd.sourceforge.net/ PMD] - PMD scans Java source code and looks for potential code problems (this is a code quality tool that does not focus on security issues)<br /> * [http://msdn.microsoft.com/en-us/library/ms933794.aspx PreFast] (Microsoft) - PREfast is a static analysis tool that identifies defects in C/C++ programs<br /> * [https://www.fortify.com/ssa-elements/threat-intelligence/rats.html RATS] (Fortify) - Scans C, C++, Perl, PHP and Python source code for security problems like buffer overflows and TOCTOU (Time Of Check, Time Of Use) race conditions<br /> * [https://www.owasp.org/index.php/Category:OWASP_SWAAT_Project OWASP SWAAT Project] - Simplistic Beta Tool - Languages: Java, JSP, ASP .Net, and PHP<br /> * [http://www.dwheeler.com/flawfinder/ Flawfinder] Flawfinder - Scans C and C++<br /> * [http://sourceforge.net/projects/rips-scanner/ RIPS] - RIPS is a static source code analyzer for vulnerabilities in PHP web applications<br /> <br /> ==Commercial Tools from OWASP Members Of This Type==<br /> <br /> These vendors have decided to support OWASP by becoming [[Membership|members]]. OWASP appreciates the support from these organizations, but cannot endorse any commercial products or services.<br /> <br /> * [http://www-01.ibm.com/software/rational/products/appscan/source/ IBM Security AppScan Source Edition] (formerly Ounce)<br /> * [http://www.armorize.com/codesecure/ Static Source Code Analysis with CodeSecure™] (Armorize Technologies)<br /> * [https://www.fortify.com/products/hpfssc/source-code-analyzer.html Source Code Analysis] (HP/Fortify)<br /> * [http://www.veracode.com/ Veracode] (Veracode)<br /> <br /> ==Other Well Known Commercial Tools Of This Type==<br /> <br /> * [http://www.checkmarx.com/Products.aspx?id=3 CxSuite] (Checkmarx)<br /> * [http://www.coverity.com/products/static-analysis.html Static Analysis] (Coverity)<br /> * [http://www.klocwork.com/products/insight.asp Insight] (KlocWork)<br /> * [http://www.parasoft.com/jsp/capabilities/static_analysis.jsp?itemId=547 Parasoft Test] (Parasoft)<br /> <br /> ==More Info==<br /> <br /> * TODO: add comments from: http://lists.owasp.org/pipermail/owasp-dotnet/2006-August/000002.html<br /> * [[Appendix_A:_Testing_Tools | Appendix A: Testing Tools]]<br /> * [http://samate.nist.gov/index.php/Source_Code_Security_Analyzers NIST's list of Source Code Security Analysis Tools]<br /> <br /> [[Category:OWASP .NET Project]]<br /> <br /> <br /> __NOTOC__</div>

Dan Anderson https://wiki.owasp.org/index.php?title=Talk:Password_Storage_Cheat_Sheet&diff=131180 2012-06-08T20:58:44Z

<p>Dan Anderson: </p> <hr /> <div>I think, for this cheat-sheet, we should begin by identifying and describing the minimum acceptable mechanisms for password storage (IMO, this is probably still salt+hash) first. Then, describe the additional controls that can be applied to further enhance the protection.<br /> --[[User:Dan Anderson|Dan Anderson]] 17:33, 8 June 2012 (UTC)<br /> <br /> <br /> IMO, this is a good example: [http://fredericiana.com/2012/06/08/lets-talk-about-password-storage/|Let’s talk about password storage]<br /> --[[User:Dan Anderson|Dan Anderson]] 20:58, 8 June 2012 (UTC)<br /> <br /> ----<br /> <br /> Since the community is focusing more on this page, I think we need a discussion.<br /> <br /> A few of the points mentioned on this page are dubious to me :<br /> <br /> ==Recommendation: Make it hard to steal the salt==<br /> As far as I know salts are salts, not secrets. They are supposed to be known (in a cryptographic point of view). <br /> <br /> * Fixed system salt is a fine practice followed by many,<br /> but does not increase system security since when concatenated with random salts, its just one long salt with less randomness.<br /> * Embedding a portion of the salt on source code, is not much different from the configuration file. Same scenario.<br /> * Generate new salt everytime password changes. That is true, and somehow required. But not to make salt gathering harder.<br /> * Salt in different location: same old<br /> ==Multiple hashes==<br /> Oddly many open source software follow this paradigm, but it's totally irrelevant. As in Merkle's TIme-Memory tradeoff and Rainbow algorithms it is obvious that multiple hashes result in the same chain or another chain of the rainbow, thus don't add a single bit of security. I believe it must be mentioned that this practice is wrong. I have seen numerous OSS use<br /> <br /> hash(salt.hash(user.hash(pass)).salt) which is as secure as hash(salt.pass) <br /> <br /> or even less (can be exploited somehow).<br /> <br /> I strongly suggest that this page be modified and fixed. If other members approve, please let me know.</div>

Dan Anderson https://wiki.owasp.org/index.php?title=Talk:Password_Storage_Cheat_Sheet&diff=131175 2012-06-08T17:33:13Z

<p>Dan Anderson: </p> <hr /> <div>I think, for this cheat-sheet, we should begin by identifying and describing the minimum acceptable mechanisms for password storage (IMO, this is probably still salt+hash) first. Then, describe the additional controls that can be applied to further enhance the protection.<br /> --[[User:Dan Anderson|Dan Anderson]] 17:33, 8 June 2012 (UTC) <br /> <br /> ----<br /> <br /> Since the community is focusing more on this page, I think we need a discussion.<br /> <br /> A few of the points mentioned on this page are dubious to me :<br /> <br /> ==Recommendation: Make it hard to steal the salt==<br /> As far as I know salts are salts, not secrets. They are supposed to be known (in a cryptographic point of view). <br /> <br /> * Fixed system salt is a fine practice followed by many,<br /> but does not increase system security since when concatenated with random salts, its just one long salt with less randomness.<br /> * Embedding a portion of the salt on source code, is not much different from the configuration file. Same scenario.<br /> * Generate new salt everytime password changes. That is true, and somehow required. But not to make salt gathering harder.<br /> * Salt in different location: same old<br /> ==Multiple hashes==<br /> Oddly many open source software follow this paradigm, but it's totally irrelevant. As in Merkle's TIme-Memory tradeoff and Rainbow algorithms it is obvious that multiple hashes result in the same chain or another chain of the rainbow, thus don't add a single bit of security. I believe it must be mentioned that this practice is wrong. I have seen numerous OSS use<br /> <br /> hash(salt.hash(user.hash(pass)).salt) which is as secure as hash(salt.pass) <br /> <br /> or even less (can be exploited somehow).<br /> <br /> I strongly suggest that this page be modified and fixed. If other members approve, please let me know.</div>

Dan Anderson https://wiki.owasp.org/index.php?title=Talk:Access_Control_Cheat_Sheet&diff=131173 2012-06-08T17:27:42Z

<p>Dan Anderson: Created page with &quot;This cheat-sheet is becoming kind of long. Can it be made more concise?&quot;</p> <hr /> <div>This cheat-sheet is becoming kind of long. Can it be made more concise?</div>

Dan Anderson https://wiki.owasp.org/index.php?title=Talk:Password_Storage_Cheat_Sheet&diff=131170 2012-06-08T17:19:09Z

<p>Dan Anderson: </p> <hr /> <div>I think, for this cheat-sheet, we should begin by identifying and describing the minimum acceptable mechanisms for password storage (IMO, this is probably still salt+hash) first. Then, describe the additional controls that can be applied to further enhance the protection. <br /> <br /> Since the community is focusing more on this page, I think we need a discussion.<br /> <br /> A few of the points mentioned on this page are dubious to me :<br /> <br /> ==Recommendation: Make it hard to steal the salt==<br /> As far as I know salts are salts, not secrets. They are supposed to be known (in a cryptographic point of view). <br /> <br /> * Fixed system salt is a fine practice followed by many,<br /> but does not increase system security since when concatenated with random salts, its just one long salt with less randomness.<br /> * Embedding a portion of the salt on source code, is not much different from the configuration file. Same scenario.<br /> * Generate new salt everytime password changes. That is true, and somehow required. But not to make salt gathering harder.<br /> * Salt in different location: same old<br /> ==Multiple hashes==<br /> Oddly many open source software follow this paradigm, but it's totally irrelevant. As in Merkle's TIme-Memory tradeoff and Rainbow algorithms it is obvious that multiple hashes result in the same chain or another chain of the rainbow, thus don't add a single bit of security. I believe it must be mentioned that this practice is wrong. I have seen numerous OSS use<br /> <br /> hash(salt.hash(user.hash(pass)).salt) which is as secure as hash(salt.pass) <br /> <br /> or even less (can be exploited somehow).<br /> <br /> I strongly suggest that this page be modified and fixed. If other members approve, please let me know.</div>

Dan Anderson https://wiki.owasp.org/index.php?title=User:Dan_Anderson&diff=129874 2012-05-15T05:20:59Z

<p>Dan Anderson: </p> <hr /> <div>CISSP, CISA, CIPP/US, Sun Certified Solaris Admin 8 &amp; 10, IBM Certified Specialist - Rational AppScan Standard Edition, NSA IAM/IEM :D<br /> <br /> I've worked in IT security on and off since 1991 in the USAF and with several civilian companies. I am currently (since 2005) a security consultant with a multi-national.<br /> <br /> My contributions: [[Special:Contributions/Dan_Anderson]]</div>

Dan Anderson https://wiki.owasp.org/index.php?title=User:Dan_Anderson&diff=128956 2012-05-03T05:04:49Z

<p>Dan Anderson: </p> <hr /> <div>CISSP, CISA, CIPP/US, Sun Certified Solaris Admin 8 &amp; 10, IBM Certified Specialist - Rational AppScan Standard Edition<br /> <br /> I've worked in IT security on and off since 1991 in the USAF and with several civilian companies. I am currently (since 2005) a security consultant with a multi-national.<br /> <br /> My contributions: [[Special:Contributions/Dan_Anderson]]</div>

Dan Anderson https://wiki.owasp.org/index.php?title=Category:Attack&diff=128955 2012-05-03T05:00:49Z

<p>Dan Anderson: Re-worked examples</p> <hr /> <div>This category is for tagging common types of application security attacks. <br /> <br /> ==What is an attack?==<br /> <br /> Attacks are the techniques that attackers use to exploit the vulnerabilities in applications. Attacks are often confused with vulnerabilities, so please try to be sure that the attack you are describing is something that an attacker would do, rather than a weakness in an application.<br /> <br /> All attack articles should follow the [[Attack template]].<br /> <br /> ==Examples:==<br /> <br /> *Brute Force: Is an exhaustive attack that works by testing every possible value of a value (password, file name, etc.) [[:Brute_force_attack|Brute_force_attack]]<br /> *Cache Poisoning: Is an attack that seeks to introduce false or malicious data into a web cache, normally via HTTP Response Splitting. [[:Cache_Poisoning|Cache_Poisoning]]<br /> *DNS Poisoning: Is an attack that seeks to introduce false DNS address information into the cache of a DNS server, where it will be served to other users enabling a variety of attacks. (e.g., Phishing)<br /> <br /> Note: many of the items marked vulnerabilities from CLASP and other places are really attacks. Some of the more obvious are:<br /> * [[Log injection]]<br /> * [[Resource exhaustion]]<br /> * [[Reflection injection]]<br /> * [[Reflection attack in an auth protocol]]<br /> <br /> <br /> [[Category:Article Type]]<br /> [[Category:OWASP ASDR Project]]</div>

Dan Anderson https://wiki.owasp.org/index.php?title=HTML5_Security_Cheat_Sheet&diff=128954 2012-05-03T04:43:30Z

<p>Dan Anderson: </p> <hr /> <div>= Introduction =<br /> <br /> The following cheat sheet serves as a guide for implementing HTML 5 in a secure fashion. <br /> <br /> == Cross Origin Resource Sharing ==<br /> <br /> *Validate URLs passed to &lt;tt&gt;XMLHttpRequest.open&lt;/tt&gt;, current browsers allow these URLs to be cross domain and this behavior can lead to code injection by a remote attacker.<br /> *Ensure that URLs responding with &lt;tt&gt;Access-Control-Allow-Origin: *&lt;/tt&gt; do not include any sensitive content or information that might aid attacker in further attacks. Use &lt;tt&gt;Access-Control-Allow-Origin&lt;/tt&gt; header only on chosen URLs that need to be accessed cross-domain. Don't use the header for the whole domain. <br /> *Take special care when using &lt;tt&gt;Access-Control-Allow-Credentials: true&lt;/tt&gt; response header. Whitelist the allowed Origins and never echo back the &lt;tt&gt;Origin&lt;/tt&gt; request header in &lt;tt&gt;Access-Control-Allow-Origin&lt;/tt&gt;. <br /> *Allow only selected, trusted domains in &lt;tt&gt;Access-Control-Allow-Origin&lt;/tt&gt; header. Prefer whitelisting domains over blacklisting or allowing any domain (either through &lt;tt&gt;*&lt;/tt&gt; wildcard or echoing the &lt;tt&gt;Origin&lt;/tt&gt; header content). <br /> *Keep in mind that CORS does not prevent the requested data from going to an un-authenticated location - it's still important for the server to perform usual [[Cross-Site Request Forgery (CSRF)|CSRF]] prevention. <br /> *While the RFC recommends a pre-flight request with the &lt;tt&gt;OPTIONS&lt;/tt&gt; verb, current implementations might not perform this request, so it's important that &quot;ordinary&quot; (&lt;tt&gt;GET&lt;/tt&gt; and &lt;tt&gt;POST&lt;/tt&gt;) requests perform any access control necessary.<br /> <br /> == Local Storage (a.k.a. Offline Storage, Web Storage) ==<br /> <br /> *Underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.<br /> *Use the object sessionStorage instead of localStorage if persistent storage is not needed. sessionStorage object is available only to that window/tab until the window is closed.<br /> *A single [[Cross-site_Scripting_(XSS)|Cross Site Scripting]] can be used to steal all the data in these objects, so again it's recommended not to store sensitive information in local storage.<br /> *A single [[Cross-site_Scripting_(XSS)|Cross Site Scripting]] can be used to load malicious data into these objects too, so don't consider objects in these to be trusted.<br /> *Pay extra attention to “localStorage.getItem” and “setItem” calls implemented in HTML5 page. It helps in detecting when developers build solutions that put sensitive information in local storage, which is a bad practice.<br /> <br /> == WebDatabase ==<br /> <br /> *Underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage. <br /> *If utilized, WebDatabase content on client side can be vulnerable to SQLInjection and needs to have proper validation and parametrization.<br /> *Like Local Storage, a single [[Cross-site_Scripting_(XSS)|Cross Site Scripting]] can be used to load malicious data into a web database too, so don't consider data in these to be trusted either.<br /> <br /> == Web Workers ==<br /> <br /> *Web Workers are allowed to use &lt;tt&gt;XMLHttpRequest&lt;/tt&gt; object to perform in-domain and Cross Origin Resource Sharing requests. See relevant section of this Cheat Sheet to ensure CORS security. <br /> *While Web Workers don't have access to DOM of the calling page, malicious Web Workers can use excessive CPU for computation, leading to Denial of Service condition or abuse Cross Origin Resource Sharing for further exploitation. Ensure code in all Web Workers scripts is not malevolent. Don't allow creating Web Worker scripts from user supplied input. <br /> *Validate messages exchanged with a Web Worker. Do not try to exchange snippets of Javascript for evaluation e.g. via eval() as that could introduce a&amp;nbsp;[[DOM Based XSS|DOM Based XSS]]&amp;nbsp;vulnerability.<br /> <br /> == WebSockets ==<br /> <br /> *Drop backward compatibility in implemented client/servers and use only protocol versions above hybi-00. Popular Hixie-76 version (hiby-00) and olders are outdated and insecure. <br /> *Recommended version due current browser support is hiby-10, supported by Firefox 7 and Chrome 14.<br /> *While it is relatively easy to tunnel TCP services through WebSockets (e.g. VNC, FTP), doing so enables access to these tunneled services for the in-browser attacker in case of a Cross-Site-Scripting attack. These services might also be called directly from a malicious page or program. <br /> *The protocol doesn't handle authorization and/or authentication. Application-level protocols should handle that separately in case sensitive data is being transferred. <br /> *Endpoints exposed through &lt;tt&gt;ws://&lt;/tt&gt; protocol are easily reversible to plaintext. Only &lt;tt&gt;wss://&lt;/tt&gt; (WebSockets over SSH) should be used for protection against Man-In-The-Middle attacks <br /> *Spoofing the client is possible outside browser, so WebSockets server should be able to handle incorrect/malicious input. Always validate input coming from the remote site, as it might have been altered. <br /> *When implementing servers, check the &lt;tt&gt;Origin:&lt;/tt&gt; header in Websockets handshake. Though it might be spoofed outside browser, browsers always add the Origin of the page which initiated Websockets connection. <br /> *As WebSockets client in browser is accessible through Javascript calls, all Websockets communication can be spoofed or hijacked through [[Cross Site Scripting Flaw|Cross-Site-Scripting]]. Always validate data coming through WebSockets connection.<br /> <br /> == Geolocation ==<br /> <br /> *The Geolocation RFC recommends that the user agent ask the user's permission before calculating location, but whether or how this decision is remembered varies from browser to browser. Some user agents require the user to visit the page again in order to turn off the ability to get the user's location without asking, so for privacy reasons, it's recommended to require user input before calling &lt;tt&gt;getCurrentPosition&lt;/tt&gt; or &lt;tt&gt;watchPosition&lt;/tt&gt;.<br /> <br /> == Use the &lt;tt&gt;sandbox&lt;/tt&gt; attribute of an &lt;tt&gt;iframe&lt;/tt&gt; for untrusted content ==<br /> <br /> *The &lt;tt&gt;sandbox&lt;/tt&gt; attribute of an &lt;tt&gt;iframe&lt;/tt&gt; enables restrictions on content within a &lt;tt&gt;iframe&lt;/tt&gt;. The following restrictions are active when the &lt;tt&gt;sandbox&lt;/tt&gt; attribute is set:<br /> <br /> #All markup is treated as being from a unique origin <br /> #All forms and scripts are disabled <br /> #All links are prevented from targeting other browsing contexts <br /> #All features that triggers automatically are blocked <br /> #All plugins are disabled<br /> <br /> It is possible to have a [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox fine-grained control] over &lt;tt&gt;iframe&lt;/tt&gt; capabilities using the value of the &lt;tt&gt;sandbox&lt;/tt&gt; attribute.<br /> <br /> == Web Messaging ==<br /> <br /> Web Messaging provides a means of messaging between documents from different origins in a way which is generally safer than JSON-P, however, there are still some recommendations to keep in mind: <br /> <br /> *When posting a message, explicitly state the expected origin as the second argument to &lt;tt&gt;postMessage&lt;/tt&gt; rather than &lt;tt&gt;*&lt;/tt&gt; in order to prevent sending the message to an unknown origin after a redirect or some other means of the target window's origin changing. <br /> *The receiving page should '''always''': <br /> **Check the &lt;tt&gt;origin&lt;/tt&gt; attribute of the sender to verify the data is originating from the expected location, and <br /> **Perform input validation on the &lt;tt&gt;data&lt;/tt&gt; attribute of the event to ensure it's in the desired format.<br /> *Don't assume you have control over data attribute. Single [[Cross-site_Scripting_(XSS)|Cross Site Scripting]] flaw in sending page allows attacker to send messages of any given format.<br /> *Both pages should only interpret the exchanged messages as '''data'''. Never evaluate passed messages as code (e.g. via eval() )&amp;nbsp;or insert it to a page DOM (e.g. via&amp;nbsp;innerHTML) as that would create a DOM based XSS vulnerability. For more information see [[DOM based XSS Prevention Cheat Sheet|DOM based XSS Prevention Cheat Sheet]].<br /> *To assign the data value to an element, instead of using a insecure method like &lt;tt&gt;element.innerHTML = data;&lt;/tt&gt; use the safer option &lt;tt&gt;element.textContent = data;&lt;/tt&gt;<br /> <br /> == Progressive Enhancements and Graceful Degradation Risks ==<br /> <br /> *The best practice now is to determine the capabilities that a browser supports and augment with some type of substitute for capabilities that are not directly supported. This may mean an onion-like element, e.g. falling through to a Flash Player if the &amp;lt;video&amp;gt; tag is unsupported, or it may mean additional scripting code from various sources that should be code reviewed.<br /> <br /> = Related Cheat Sheets =<br /> <br /> {{Cheatsheet_Navigation}} <br /> <br /> = Authors and Primary Editors =<br /> <br /> Mark Roxbury - mark.roxberry [at] owasp.org <br /> <br /> Krzysztof Kotowicz - krzysztof [at] kotowicz.net <br /> <br /> Will Stranathan - will [at] cltnc.us <br /> <br /> Shreeraj Shah - shreeraj.shah [at] blueinfy.net <br /> <br /> Juan Galiana Lara - jgaliana [at] owasp.org<br /> <br /> [[Category:How_To]] [[Category:Cheatsheets]]</div>

Dan Anderson https://wiki.owasp.org/index.php?title=OWASP_AJAX_Security_Guidelines&diff=127803 2012-04-13T06:31:05Z

<p>Dan Anderson: spelling</p> <hr /> <div>= AJAX Security Guidelines =<br /> <br /> There is a complete lack of guidelines for AJAX. This document will provide a starting point for AJAX security and will hopefully be updated and expanded reasonably often to provide more detailed information about specific frameworks and technologies.<br /> <br /> == Client Side (Javascript) ==<br /> <br /> === Use .innerText instead of .innerHtml ===<br /> <br /> The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.<br /> <br /> === Don't use eval ===<br /> <br /> Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.<br /> <br /> === Canonicalize data to consumer (read: encode before use) ===<br /> <br /> When using data to build HTML, script, CSS, XML, JSON, etc. make sure you take into account how that data must be presented in a literal sense to keep it's logical meaning. Data should be properly encoded before used in this manner to prevent injection style issues, and to make sure the logical meaning is preserved.<br /> <br /> [[:Category:OWASP_Encoding_Project|Check out the OWASP Encoding Project.]]<br /> <br /> === Don't rely on client logic for security ===<br /> <br /> Least ye have forgotten the user controls the client side logic. I can use a number of browser plugging to set breakpoints, skip code, change values, etc. Never rely on client logic.<br /> <br /> === Don't rely on client business logic ===<br /> <br /> Just like the security one, make sure any interesting business rules/logic is duplicated on the server side less a user bypass needed logic and do something silly, or worse, costly.<br /> <br /> === Avoid writing serialization code ===<br /> <br /> This is hard and even a small mistake can cause large security issues. There are already a lot of frameworks to provide this functionality. Take a look at the [http://www.json.org/ JSON page] for links.<br /> <br /> === Avoid building XML dynamically ===<br /> <br /> Just like building HTML or SQL you will cause XML injection bugs, so stay way from this or at least use an encoding library to make attributes and element data safe.<br /> <br /> [[:Category:OWASP_Encoding_Project|Check out the OWASP Encoding Project.]]<br /> <br /> === Never transmit secrets to the client ===<br /> <br /> Anything the client knows the user will also know, so keep all that secret stuff on the server please.<br /> <br /> === Don't perform encryption in client side code ===<br /> <br /> Use SSL and encrypt on the server!<br /> <br /> === Don't perform security impacting logic on client side ===<br /> <br /> This is the overall one that gets me out of trouble in case I missed something :) <br /> <br /> == JSON ==<br /> <br /> === Never send JSON via Querystring ===<br /> <br /> Sending JSON over a querystring would typically cause a cross-site scripting vulnerability as JSON strings are eval'd by the Javascript. JSON content should always come from a trusted source as the content body.<br /> <br /> === Always return JSON with an Object on the outside ===<br /> <br /> Always have the outside primitive be an object for JSON strings. This will help mitigate so called &quot;JavaScript Hijacking&quot; as talked about in [http://www.fortifysoftware.com/servlet/downloads/public/JavaScript_Hijacking.pdf this paper].<br /> <br /> '''Explotable:'''<br /> &lt;pre&gt;<br /> [{&quot;object&quot;: &quot;inside an array&quot;}]<br /> &lt;/pre&gt;<br /> <br /> '''Not exploitable:'''<br /> &lt;pre&gt;<br /> {&quot;object&quot;: &quot;not inside an array&quot;}<br /> &lt;/pre&gt;<br /> <br /> '''Also not exploitable:'''<br /> &lt;pre&gt;<br /> {&quot;result&quot;: [{&quot;object&quot;: &quot;inside an array&quot;}]}<br /> &lt;/pre&gt;<br /> <br /> == ASP.NET ==<br /> <br /> <br /> === Avoid writing serialization code. Remember ref vs. value types! ===<br /> <br /> Writing serialization code in .NET seems not to hard and yet everyone gets it wrong. Look for an existing library that has been reviewed. I'll post more on that as I eval them.<br /> <br /> === Services can be called by users directly ===<br /> <br /> Even though you only expect your AJAX client side code to call those services the users can too. Make sure you validate inputs and treat them like they are under user control (because they are!).<br /> <br /> === Web service calls are not schema verified ===<br /> <br /> You need to use a 3rd party library to validate web services. <br /> <br /> [[:.NET_Web_Service_Validation|Check out OWASP .NET Web Service Validation.]]<br /> <br /> === Avoid building XML by hand, use the framework ===<br /> <br /> Use the framework and be safe, do it by hand and have security issues. Simple.<br /> <br /> === Avoid building JSON by hand, use an existing framework ===<br /> <br /> This is to hard to get right. Use existing code for this. Check out the JSON site for information. <br /> <br /> A guide for building a secure AJAX service layer can be found [http://msdn.microsoft.com/en-us/magazine/cc793961.aspx here].<br /> <br /> == Java ==<br /> <br /> Coming soon....maybe...<br /> <br /> <br /> [[Category:OWASP AJAX Security Project]]<br /> [[Category:AJAX]]</div>

Dan Anderson