https://wiki.owasp.org/api.php?action=feedcontributions&feedformat=atom&user=Jorge+Correa 2026-05-09T11:47:04Z User contributions MediaWiki 1.27.2 https://wiki.owasp.org/index.php?title=Category:Penetration_Testing_Tools&diff=164299 2013-12-04T16:47:27Z

<p>Jorge Correa: </p> <hr /> <div>{{Template:Stub}}<br /> [[Category:OWASP Tools Project]]<br /> <br /> == Penetration Testing Tools ==<br /> <br /> <br /> === Information Gathering Tools ===<br /> *'''Fingerprinting'''<br /> <br /> {{:Template:OWASP Tool Headings}}<br /> {{OWASP Tool Info | tool_name = [http://net-square.com/httprint/index.shtml httprint]<br /> | tool_owner = NetSquare Inc<br /> | tool_licence = no cost for personal, educational and non-commercial use.<br /> | tool_platforms = Win, Lin, Mac, FreeBSD<br /> }}<br /> {{OWASP Tool Info | tool_name = [http://www.computec.ch/projekte/httprecon/ httprecon]<br /> | tool_owner = Marc Ruef<br /> | tool_licence = GPL<br /> | tool_platforms = Win<br /> }}<br /> {{OWASP Tool Info | tool_name = [http://www.netcraft.com Netcraft]| tool_owner = Netcraft Inc <br /> | tool_licence = N/A | tool_platforms = WebBased<br /> }}<br /> {{OWASP Tool Info | tool_name = [http://yehg.net/q WebRecon]| tool_owner = Aung Khant<br /> | tool_licence =GPL | tool_platforms = WebBased<br /> }}<br /> |}<br /> <br /> === Configuration Management Testing Tools ===<br /> *'''SSL Testing'''<br /> <br /> {{:Template:OWASP Tool Headings}}<br /> {{OWASP Tool Info || tool_name = [http://www.openssl.org/ OpenSSL]}}<br /> {{OWASP Tool Info || tool_name = [http://www.foundstone.com/us/resources/proddesc/ssldigger.htm SSL Digger]}}<br /> |}<br /> <br /> *''' DB Listener Testing'''<br /> <br /> {{:Template:OWASP Tool Headings}}<br /> {{OWASP Tool Info || tool_name = [http://www.jammed.com/%7Ejwa/hacks/security/tnscmd/tnscmd-doc.html TNS Listener]}}<br /> {{OWASP Tool Info || tool_name = [http://www.quest.com/toad Toad]}}<br /> |}<br /> <br /> <br /> === Authentication Testing Tools ===<br /> *'''Password Brute Force Testing'''<br /> <br /> {{:Template:OWASP Tool Headings}}<br /> {{OWASP Tool Info || tool_name = [http://portswigger.net/intruder/ Burp Intruder]}}<br /> {{OWASP Tool Info || tool_name = [http://www.hoobie.net/brutus/ Brutus]}}<br /> {{OWASP Tool Info || tool_name = [http://www.oxid.it/cain.html Cain &amp; Abel] | tool_owner = oxid <br /> | tool_licence = Freeware | tool_platforms = Windows}}<br /> {{OWASP Tool Info || tool_name = [http://www.openwall.com/john/ John the Ripper]}}<br /> {{OWASP Tool Info || tool_name = [http://ophcrack.sourceforge.net/ Ophcrack]}}<br /> {{OWASP Tool Info || tool_name = [http://www.thc.org/thc-hydra/ THC Hydra] | tool_owner= The Hacker's Choise | tool_platforms = Lin}}<br /> |}<br /> <br /> <br /> === Session Management Testing Tools ===<br /> <br /> {{:Template:OWASP Tool Headings}}<br /> {{OWASP Tool Info || tool_name = [http://www.foundstone.com/us/resources/proddesc/cookiedigger.htm CookieDigger]}}<br /> |}<br /> <br /> <br /> === Authorization Testing Tools ===<br /> <br /> <br /> === Data Validation Testing Tools ===<br /> *'''Fuzzers'''<br /> *'''SQL Injection Testing'''<br /> *'''XSS Testing'''<br /> *'''Buffer Overflow Testing'''<br /> {{:Template:OWASP Tool Headings}}<br /> {{OWASP Tool Info | tool_name = [http://code.google.com/p/skipfish/ Skipfish] <br /> | tool_owner = N/A <br /> | tool_licence = Apache <br /> | tool_platforms = Linux<br /> }}<br /> {{OWASP Tool Info || tool_name = [http://w3af.sourceforge.net/ w3af] | tool_owner = NA <br /> | tool_licence = GPL v2 | tool_platforms = Python required (cross platform)<br /> }}<br /> |}<br /> <br /> <br /> === Denial of Service Testing Tools ===<br /> <br /> <br /> === Web Services Testing Tools ===<br /> <br /> <br /> === Ajax Testing Tools ===<br /> <br /> <br /> === HTTP Traffic Monitoring ===<br /> *'''Web Proxies'''<br /> <br /> {{:Template:OWASP Tool Headings}}<br /> {{OWASP Tool Info || tool_name = [http://portswigger.net/proxy/ Burp Suite]}}<br /> {{OWASP Tool Info || tool_name = [http://www.parosproxy.org/download.shtml Paros Proxy]}}<br /> {{OWASP Tool Info || tool_name = [[OWASP_WebScarab_Project|Webscarab]]}}<br /> {{OWASP Tool Info || tool_name = [http://www.bayden.com/TamperIE/ TamperIE]}}<br /> {{OWASP Tool Info || tool_name = [https://addons.mozilla.org/en-US/firefox/addon/966 Tamper Data]}}<br /> {{OWASP Tool Info || tool_name = [http://www.immunitysec.com/resources-freesoftware.shtml SPIKE Proxy]}}<br /> {{OWASP Tool Info || tool_name = [http://www.sensepost.com/research/suru/ Suru Web Proxy]}}<br /> {{OWASP Tool Info || tool_name = [http://www.charlesproxy.com/ Charles]}}<br /> {{OWASP Tool Info || tool_name = [http://www.bindshell.net/tools/odysseus Odysseus]}}<br /> {{OWASP Tool Info || tool_name = [http://jscmd.rubyforge.org/ JS Commander]}}<br /> {{OWASP Tool Info || tool_name = [http://code.google.com/p/ratproxy/ ratproxy]}}<br /> |}<br /> <br /> *'''Sniffers'''<br /> <br /> === Encoders / Decoders ===<br /> *'''CAPTCHA Decoders'''<br /> <br /> {{:Template:OWASP Tool Headings}}<br /> {{OWASP Tool Info || tool_name = [http://caca.zoy.org/wiki/PWNtcha PWNtcha]}}<br /> {{OWASP Tool Info || tool_name = [http://churchturing.org/captcha-dist/ The Captcha Breaker]}}<br /> |}<br /> <br /> === Web Testing Frameworks ===<br /> <br /> {{:Template:OWASP Tool Headings}}<br /> {{OWASP Tool Info | tool_name = [http://w3af.sourceforge.net/ w3af]<br /> | tool_owner = Andres Riancho and w3af team<br /> | tool_licence = GPLv2<br /> | tool_platforms = Windows, Linux<br /> }}<br /> {{OWASP Tool Info | tool_name = [http://www.websecurify.com Websecurify]<br /> | tool_owner = GNUCITIZEN / Websecurify<br /> | tool_licence = GPLv2<br /> | tool_platforms = Windows, Mac OS, Linux<br /> }}<br /> {{OWASP Tool Info | tool_name = [http://www.zerodayscan.com/ ZeroDayScan] <br /> | tool_owner = <br /> | tool_licence = Free<br /> | tool_platforms = Online, Cloud<br /> }}</div>

Jorge Correa https://wiki.owasp.org/index.php?title=Category:Penetration_Testing_Tools&diff=164298 2013-12-04T16:46:39Z

<p>Jorge Correa: </p> <hr /> <div>{{Template:Stub}}<br /> [[Category:OWASP Tools Project]]<br /> <br /> == Penetration Testing Tools ==<br /> <br /> <br /> === Information Gathering Tools ===<br /> *'''Fingerprinting'''<br /> <br /> {{:Template:OWASP Tool Headings}}<br /> {{OWASP Tool Info | tool_name = [http://net-square.com/httprint/index.shtml httprint]<br /> | tool_owner = NetSquare Inc<br /> | tool_licence = no cost for personal, educational and non-commercial use.<br /> | tool_platforms = Win, Lin, Mac, FreeBSD<br /> }}<br /> {{OWASP Tool Info | tool_name = [http://www.computec.ch/projekte/httprecon/ httprecon]<br /> | tool_owner = Marc Ruef<br /> | tool_licence = GPL<br /> | tool_platforms = Win<br /> }}<br /> {{OWASP Tool Info | tool_name = [http://www.netcraft.com Netcraft]| tool_owner = Netcraft Inc <br /> | tool_licence = N/A | tool_platforms = WebBased<br /> }}<br /> {{OWASP Tool Info | tool_name = [http://yehg.net/q WebRecon]| tool_owner = Aung Khant<br /> | tool_licence =GPL | tool_platforms = WebBased<br /> }}<br /> |}<br /> <br /> === Configuration Management Testing Tools ===<br /> *'''SSL Testing'''<br /> <br /> {{:Template:OWASP Tool Headings}}<br /> {{OWASP Tool Info || tool_name = [http://www.openssl.org/ OpenSSL]}}<br /> {{OWASP Tool Info || tool_name = [http://www.foundstone.com/us/resources/proddesc/ssldigger.htm SSL Digger]}}<br /> |}<br /> <br /> *''' DB Listener Testing'''<br /> <br /> {{:Template:OWASP Tool Headings}}<br /> {{OWASP Tool Info || tool_name = [http://www.jammed.com/%7Ejwa/hacks/security/tnscmd/tnscmd-doc.html TNS Listener]}}<br /> {{OWASP Tool Info || tool_name = [http://www.quest.com/toad Toad]}}<br /> |}<br /> <br /> <br /> === Authentication Testing Tools ===<br /> *'''Password Brute Force Testing'''<br /> <br /> {{:Template:OWASP Tool Headings}}<br /> {{OWASP Tool Info || tool_name = [http://portswigger.net/intruder/ Burp Intruder]}}<br /> {{OWASP Tool Info || tool_name = [http://www.hoobie.net/brutus/ Brutus]}}<br /> {{OWASP Tool Info || tool_name = [http://www.oxid.it/cain.html Cain &amp; Abel] | tool_owner = oxid <br /> | tool_licence = Freeware | tool_platforms = Windows}}<br /> {{OWASP Tool Info || tool_name = [http://www.openwall.com/john/ John the Ripper]}}<br /> {{OWASP Tool Info || tool_name = [http://ophcrack.sourceforge.net/ Ophcrack]}}<br /> {{OWASP Tool Info || tool_name = [http://www.thc.org/thc-hydra/ THC Hydra] | tool_owner= The Hacker's Choise | tool_platforms = Lin--[[User:Jorge Correa|Jorge Correa]] ([[User talk:Jorge Correa|talk]]) 10:46, 4 December 2013 (CST)}}<br /> |}<br /> <br /> <br /> === Session Management Testing Tools ===<br /> <br /> {{:Template:OWASP Tool Headings}}<br /> {{OWASP Tool Info || tool_name = [http://www.foundstone.com/us/resources/proddesc/cookiedigger.htm CookieDigger]}}<br /> |}<br /> <br /> <br /> === Authorization Testing Tools ===<br /> <br /> <br /> === Data Validation Testing Tools ===<br /> *'''Fuzzers'''<br /> *'''SQL Injection Testing'''<br /> *'''XSS Testing'''<br /> *'''Buffer Overflow Testing'''<br /> {{:Template:OWASP Tool Headings}}<br /> {{OWASP Tool Info | tool_name = [http://code.google.com/p/skipfish/ Skipfish] <br /> | tool_owner = N/A <br /> | tool_licence = Apache <br /> | tool_platforms = Linux<br /> }}<br /> {{OWASP Tool Info || tool_name = [http://w3af.sourceforge.net/ w3af] | tool_owner = NA <br /> | tool_licence = GPL v2 | tool_platforms = Python required (cross platform)<br /> }}<br /> |}<br /> <br /> <br /> === Denial of Service Testing Tools ===<br /> <br /> <br /> === Web Services Testing Tools ===<br /> <br /> <br /> === Ajax Testing Tools ===<br /> <br /> <br /> === HTTP Traffic Monitoring ===<br /> *'''Web Proxies'''<br /> <br /> {{:Template:OWASP Tool Headings}}<br /> {{OWASP Tool Info || tool_name = [http://portswigger.net/proxy/ Burp Suite]}}<br /> {{OWASP Tool Info || tool_name = [http://www.parosproxy.org/download.shtml Paros Proxy]}}<br /> {{OWASP Tool Info || tool_name = [[OWASP_WebScarab_Project|Webscarab]]}}<br /> {{OWASP Tool Info || tool_name = [http://www.bayden.com/TamperIE/ TamperIE]}}<br /> {{OWASP Tool Info || tool_name = [https://addons.mozilla.org/en-US/firefox/addon/966 Tamper Data]}}<br /> {{OWASP Tool Info || tool_name = [http://www.immunitysec.com/resources-freesoftware.shtml SPIKE Proxy]}}<br /> {{OWASP Tool Info || tool_name = [http://www.sensepost.com/research/suru/ Suru Web Proxy]}}<br /> {{OWASP Tool Info || tool_name = [http://www.charlesproxy.com/ Charles]}}<br /> {{OWASP Tool Info || tool_name = [http://www.bindshell.net/tools/odysseus Odysseus]}}<br /> {{OWASP Tool Info || tool_name = [http://jscmd.rubyforge.org/ JS Commander]}}<br /> {{OWASP Tool Info || tool_name = [http://code.google.com/p/ratproxy/ ratproxy]}}<br /> |}<br /> <br /> *'''Sniffers'''<br /> <br /> === Encoders / Decoders ===<br /> *'''CAPTCHA Decoders'''<br /> <br /> {{:Template:OWASP Tool Headings}}<br /> {{OWASP Tool Info || tool_name = [http://caca.zoy.org/wiki/PWNtcha PWNtcha]}}<br /> {{OWASP Tool Info || tool_name = [http://churchturing.org/captcha-dist/ The Captcha Breaker]}}<br /> |}<br /> <br /> === Web Testing Frameworks ===<br /> <br /> {{:Template:OWASP Tool Headings}}<br /> {{OWASP Tool Info | tool_name = [http://w3af.sourceforge.net/ w3af]<br /> | tool_owner = Andres Riancho and w3af team<br /> | tool_licence = GPLv2<br /> | tool_platforms = Windows, Linux<br /> }}<br /> {{OWASP Tool Info | tool_name = [http://www.websecurify.com Websecurify]<br /> | tool_owner = GNUCITIZEN / Websecurify<br /> | tool_licence = GPLv2<br /> | tool_platforms = Windows, Mac OS, Linux<br /> }}<br /> {{OWASP Tool Info | tool_name = [http://www.zerodayscan.com/ ZeroDayScan] <br /> | tool_owner = <br /> | tool_licence = Free<br /> | tool_platforms = Online, Cloud<br /> }}</div>

Jorge Correa https://wiki.owasp.org/index.php?title=OWASP_Top_Ten_Cheat_Sheet&diff=137510 2012-10-11T00:00:07Z

<p>Jorge Correa: </p> <hr /> <div>= Introduction =<br /> <br /> The following is a developer-centric defensive cheat sheet for the [[OWASP Top Ten Project]]. It also presents a quick reference based on [[OWASP Testing Project]] to help how to identify the risks.<br /> <br /> = OWASP Top Ten Cheat Sheet =<br /> <br /> {| border=1<br /> | <br /> ||'''Presentation'''<br /> ||'''Controller'''<br /> ||'''Model'''<br /> ||'''Testing (OWASP Testing Guide V3)'''<br /> <br /> |-<br /> |'''A1 Injection'''<br /> ||<br /> <br /> ''Render:''<br /> *Set a correct content type<br /> *Set safe character set (UTF-8)<br /> *Set correct locale<br /> <br /> ''On Submit:''<br /> *Enforce input field type and lengths.<br /> *Validate fields and provide feedback.<br /> *Ensure option selects and radio contain only sent values.<br /> ||'''Canonicalize using correct character set'''<br /> '''Positive input validation using correct character set'''<br /> <br /> (NR) Negative input validation.<br /> (LR) Sanitize input.<br /> <br /> ''Tip: updating a negative list (such as looking for &quot;script&quot;, &quot;sCrIpT&quot;, &quot;ßCrîpt&quot;, etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of &quot;bad&quot; words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. ''<br /> ||*'''[https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet Parameterized queries]'''<br /> <br /> *Object relational model (Hibernate).<br /> *Active Record design pattern.<br /> *Stored procedures.<br /> <br /> *Escape mechanisms such as ESAPI's Encoder:<br /> **EncodeForLDAP()<br /> **Encoder.EncodeforOS()<br /> <br /> ''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization ''<br /> <br /> ||''4.8.5 SQL Injection (OWASP-DV-005)''<br /> ''4.8.6 LDAP Injection (OWASP-DV-006)''<br /> ''4.8.7 ORM Injection (OWASP-DV-007)''<br /> ''4.8.8 XML Injection (OWASP-DV-008)''<br /> ''4.8.9 SSI Injection (OWASP-DV-009)''<br /> ''4.8.10 XPath Injection (OWASP-DV-010)''<br /> ''4.8.11 IMAP/SMTP Injection (OWASP-DV-011)''<br /> ''4.8.12 Code Injection (OWASP-DV-012)''<br /> ''4.8.13 OS Commanding (OWASP-DV-013)''<br /> ''4.8.14 Buffer overflow (OWASP-DV-014)''<br /> <br /> <br /> |-<br /> |'''A2 XSS'''<br /> ||<br /> <br /> ''Render:''<br /> *Set correct content type<br /> *Set safe character set (UTF-8)<br /> *Set correct locale<br /> *Output encode all user data as per output context<br /> *Set input constraints<br /> <br /> ''On Submit:''<br /> *Enforce input field type and lengths.<br /> *Validate fields and provide feedback.<br /> *Ensure option selects and radio contain only sent values.<br /> ||'''Canonicalize using correct character set'''<br /> '''Positive input validation using correct character set'''<br /> <br /> (NR) Negative input validation <br /> (LR) Sanitize input <br /> <br /> ''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.''<br /> ||''Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.''<br /> <br /> ''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data''<br /> <br /> ||''4.8.1 Testing for Reflected Cross Site Scripting (OWASP-DV-001)''<br /> ''4.8.2 Testing for Stored Cross Site Scripting (OWASP-DV-002)''<br /> ''4.8.3 Testing for DOM based Cross Site Scripting (OWASP-DV-003)''<br /> ''4.8.4 Testing for Cross Site Flashing (OWASP-DV004)''<br /> <br /> <br /> |-<br /> |'''A3 Weak authentication and session management'''<br /> ||''Render:''<br /> *Validate user is authenticated.<br /> *Validate role is sufficient for this view.<br /> *Set &quot;secure&quot; and &quot;HttpOnly&quot; flags for session cookies.<br /> *Send CSRF token with forms.<br /> <br /> ||''Design:''<br /> *Only use inbuilt session management.<br /> *Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies.<br /> <br /> *Validate user is authenticated.<br /> *Validate role is sufficient to perform this action.<br /> *Validate CSRF token.<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ''Tip: Consider the use of a &quot;governor&quot; to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.''<br /> <br /> ||''4.4.2 Testing for user enumeration (OWASP-AT-002)''<br /> ''4.4.3 Testing for Guessable (Dictionary) User Account (OWASP-AT-003)''<br /> ''4.4.4 Brute Force Testing (OWASP-AT-004)''<br /> ''4.4.6 Testing for vulnerable remember password and pwd reset (OWASP-AT-006)''<br /> ''4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)''<br /> ''4.4.7 Testing for Logout and Browser Cache Management (OWASP-AT-007)''<br /> ''4.4.8 Testing for CAPTCHA (OWASP-AT-008)''<br /> ''4.4.9 Testing Multiple Factors Authentication (OWASP-AT-009)''<br /> ''4.4.10 Testing for Race Conditions (OWASP-AT-010)''<br /> ''4.5.1 Testing for Session Management Schema (OWASP-SM-001)''<br /> ''4.5.2 Testing for Cookies attributes (OWASP-SM-002)''<br /> ''4.5.3 Testing for Session Fixation (OWASP-SM_003)''<br /> ''4.5.4 Testing for Exposed Session Variables (OWASP-SM-004)''<br /> ''4.5.5 Testing for CSRF (OWASP-SM-005)''<br /> ''4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)''<br /> ''4.6.3 Testing for Privilege Escalation (OWASP-AZ-003)''<br /> <br /> <br /> |-<br /> |'''A4 Insecure Direct Object Reference'''<br /> ||If data is from internal trusted sources, no data is sent.<br /> <br /> Or<br /> <br /> ''Render:''<br /> *Send indirect random access reference map value.<br /> ||Obtain data from internal, trusted sources.<br /> <br /> Or<br /> <br /> Obtain direct value from random access reference access map.<br /> ||Validate role is sufficient to create, read, update, or delete data.<br /> <br /> ||''4.6.1 Testing for Path Traversal (OWASP-AZ-001)''<br /> <br /> |-<br /> |'''A5 Cross Site Request Forgery'''<br /> ||''Pre-render:''<br /> *Validate user is authenticated<br /> *Validate role is sufficient for this view<br /> <br /> ''Render:''<br /> *Send CSRF token.<br /> *Set &quot;secure&quot; and &quot;HttpOnly&quot; flags for session cookies.<br /> ||<br /> *Validate CSRF token.<br /> *Validate role is sufficient to perform this action.<br /> *Validate role is sufficient.<br /> <br /> ''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.5.5 Testing for CSRF (OWASP-SM-005)''<br /> <br /> |-<br /> |'''A6 Security Misconfiguration'''<br /> ||Ensure web servers and application servers are hardened.<br /> <br /> PHP: Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension <br /> ||Ensure web servers and application servers are hardened <br /> <br /> XML: Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer. <br /> ||Ensure database servers are hardened <br /> <br /> ||''4.2.6 Analysis of Error Codes (OWASP-IG-006)''<br /> ''4.3.2 DB Listener Testing (OWASP-CM-002)''<br /> ''4.3.3 Infrastructure Configuration Management Testing (OWASP-CM-003)''<br /> ''4.3.4 Application Configuration Management Testing (OWASP-CM-004)''<br /> ''4.3.5 Testing for File Extensions Handling (OWASP-CM-005)''<br /> ''4.3.6 Old, Backup and Unreferenced Files (OWASP-CM-006)''<br /> ''4.3.7 Infrastructure and Application Admin Interfaces (OWASP-CM-007)''<br /> ''4.3.8 Testing for HTTP Methods and XST (OWASP-CM-008)''<br /> <br /> <br /> |-<br /> |'''A7 Insufficient Cryptographic Storage'''<br /> ||''Design:''<br /> *Use strong ciphers (AES 128 or better).<br /> *Use strong hashes (SHA 256 or better) with salts for passwords.<br /> *Protect keys more than any other asset.<br /> <br /> ''Render:''<br /> *Do not send keys or hashes to the browser.<br /> <br /> ||''Design:''<br /> *Use strong ciphers (AES 128 or better).<br /> *Use strong hashes (SHA 256 or better) with salts for passwords.<br /> *Protect keys more than any other asset.<br /> <br /> ''Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen. ''<br /> <br /> ''Tip: It is best to encrypt data on the application server, rather than the database server.''<br /> <br /> ||''Design:''<br /> <br /> ''Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being &quot;encrypted&quot; on disk. ''<br /> <br /> ||<br /> <br /> <br /> |-<br /> |'''A8 Failure to Restrict URL access'''<br /> ||''Design:''<br /> *Ensure all non-web data is outside the web root (logs, configuration, etc).<br /> *Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar.<br /> *Ensure every page requires a role, even if it is &quot;guest&quot;.<br /> <br /> ''Pre-render:''<br /> *Validate user is authenticated.<br /> *Validate role is sufficient to view secured URL.<br /> <br /> ''Render:''<br /> *Send CSRF token.<br /> ||<br /> *Validate user is authenticated.<br /> *Validate role is sufficient to perform secured action.<br /> *Validate CSRF token.<br /> <br /> ''Tip: It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming. ''<br /> <br /> ''Tip: Assume attackers '''will''' learn where &quot;hidden&quot; directories and &quot;random&quot; filenames are, so do not store these files in the web root, even if they are not directly linked.''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)''<br /> ''4.6.1 Testing for Path Traversal (OWASP-AZ-001)''<br /> ''4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)''<br /> <br /> |-<br /> |'''A9 Insufficient Transport Layer Protection'''<br /> ||<br /> *Use TLS 1.2 or later for all web communications.<br /> *Buy extended validation (EV) certificates for public web servers.<br /> <br /> ''Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.''<br /> ||<br /> *Mandate strong encrypted communications between web and database servers and any other servers or administrative users.<br /> ||<br /> *Mandate strong encrypted communications with application servers and any other servers or administrative users.<br /> <br /> ||''4.3.1 SSL/TLS Testing (OWASP-CM-001)''<br /> ''4.4.1 Credentials transport over an encrypted channel (OWASP-AT-001)''<br /> <br /> |-<br /> |'''A10 Unvalidated Redirects and Forwards'''<br /> ||<br /> *Design the app without URL redirection parameters.<br /> <br /> or<br /> <br /> ''Render:''<br /> *Use random indirect object references for redirection parameters.<br /> <br /> ||<br /> *Design the app without URL redirection parameters.<br /> <br /> or<br /> <br /> *Obtain direct redirection parameter from random indirect reference access map.<br /> *(LR) Positive validation of redirection parameter.<br /> *(NR) Java – Do not forward() requests as this prevents SSO access control mechanisms.<br /> <br /> ||<br /> *Validate role is sufficient to create, read, update, or delete data.<br /> <br /> ||<br /> <br /> |-<br /> |}<br /> <br /> = Authors and Primary Editors =<br /> <br /> Andrew van der Stock vanderaj[at]owasp.org<br /> <br /> Ismael Rocha Gonçalves ismaelrg[at]gmail.com<br /> <br /> Jorge Correa jacorream@gmail.com<br /> <br /> = Other Cheatsheets =<br /> {{Cheatsheet_Navigation}}<br /> <br /> [[Category:Cheatsheets]]</div>

Jorge Correa https://wiki.owasp.org/index.php?title=OWASP_Top_Ten_Cheat_Sheet&diff=137509 2012-10-10T23:59:35Z

<p>Jorge Correa: </p> <hr /> <div>= Introduction =<br /> <br /> The following is a developer-centric defensive cheat sheet for the [[OWASP Top Ten Project]]. It also presents a quick reference based on [[OWASP Testing Project]] to help how to identify the risks.<br /> <br /> = OWASP Top Ten Cheat Sheet =<br /> <br /> {| border=1<br /> | <br /> ||'''Presentation'''<br /> ||'''Controller'''<br /> ||'''Model'''<br /> ||'''Testing (OWASP Testing Guide V3)'''<br /> <br /> |-<br /> |'''A1 Injection'''<br /> ||<br /> <br /> ''Render:''<br /> *Set a correct content type<br /> *Set safe character set (UTF-8)<br /> *Set correct locale<br /> <br /> ''On Submit:''<br /> *Enforce input field type and lengths.<br /> *Validate fields and provide feedback.<br /> *Ensure option selects and radio contain only sent values.<br /> ||'''Canonicalize using correct character set'''<br /> '''Positive input validation using correct character set'''<br /> <br /> (NR) Negative input validation.<br /> (LR) Sanitize input.<br /> <br /> ''Tip: updating a negative list (such as looking for &quot;script&quot;, &quot;sCrIpT&quot;, &quot;ßCrîpt&quot;, etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of &quot;bad&quot; words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. ''<br /> ||*'''[https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet Parameterized queries]'''<br /> <br /> *Object relational model (Hibernate).<br /> *Active Record design pattern.<br /> *Stored procedures.<br /> <br /> *Escape mechanisms such as ESAPI's Encoder:<br /> **EncodeForLDAP()<br /> **Encoder.EncodeforOS()<br /> <br /> ''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization ''<br /> <br /> ||''4.8.5 SQL Injection (OWASP-DV-005)''<br /> ''4.8.6 LDAP Injection (OWASP-DV-006)''<br /> ''4.8.7 ORM Injection (OWASP-DV-007)''<br /> ''4.8.8 XML Injection (OWASP-DV-008)''<br /> ''4.8.9 SSI Injection (OWASP-DV-009)''<br /> ''4.8.10 XPath Injection (OWASP-DV-010)''<br /> ''4.8.11 IMAP/SMTP Injection (OWASP-DV-011)''<br /> ''4.8.12 Code Injection (OWASP-DV-012)''<br /> ''4.8.13 OS Commanding (OWASP-DV-013)''<br /> ''4.8.14 Buffer overflow (OWASP-DV-014)''<br /> <br /> <br /> |-<br /> |'''A2 XSS'''<br /> ||<br /> <br /> ''Render:''<br /> *Set correct content type<br /> *Set safe character set (UTF-8)<br /> *Set correct locale<br /> *Output encode all user data as per output context<br /> *Set input constraints<br /> <br /> ''On Submit:''<br /> *Enforce input field type and lengths.<br /> *Validate fields and provide feedback.<br /> *Ensure option selects and radio contain only sent values.<br /> ||'''Canonicalize using correct character set'''<br /> '''Positive input validation using correct character set'''<br /> <br /> (NR) Negative input validation <br /> (LR) Sanitize input <br /> <br /> ''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.''<br /> ||''Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.''<br /> <br /> ''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data''<br /> <br /> ||''4.8.1 Testing for Reflected Cross Site Scripting (OWASP-DV-001)''<br /> ''4.8.2 Testing for Stored Cross Site Scripting (OWASP-DV-002)''<br /> ''4.8.3 Testing for DOM based Cross Site Scripting (OWASP-DV-003)''<br /> ''4.8.4 Testing for Cross Site Flashing (OWASP-DV004)''<br /> <br /> <br /> |-<br /> |'''A3 Weak authentication and session management'''<br /> ||''Render:''<br /> *Validate user is authenticated.<br /> *Validate role is sufficient for this view.<br /> *Set &quot;secure&quot; and &quot;HttpOnly&quot; flags for session cookies.<br /> *Send CSRF token with forms.<br /> <br /> ||''Design:''<br /> *Only use inbuilt session management.<br /> *Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies.<br /> <br /> *Validate user is authenticated.<br /> *Validate role is sufficient to perform this action.<br /> *Validate CSRF token.<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ''Tip: Consider the use of a &quot;governor&quot; to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.''<br /> <br /> ||''4.4.2 Testing for user enumeration (OWASP-AT-002)''<br /> ''4.4.3 Testing for Guessable (Dictionary) User Account (OWASP-AT-003)''<br /> ''4.4.4 Brute Force Testing (OWASP-AT-004)''<br /> ''4.4.6 Testing for vulnerable remember password and pwd reset (OWASP-AT-006)''<br /> ''4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)''<br /> ''4.4.7 Testing for Logout and Browser Cache Management (OWASP-AT-007)''<br /> ''4.4.8 Testing for CAPTCHA (OWASP-AT-008)''<br /> ''4.4.9 Testing Multiple Factors Authentication (OWASP-AT-009)''<br /> ''4.4.10 Testing for Race Conditions (OWASP-AT-010)''<br /> ''4.5.1 Testing for Session Management Schema (OWASP-SM-001)''<br /> ''4.5.2 Testing for Cookies attributes (OWASP-SM-002)''<br /> ''4.5.3 Testing for Session Fixation (OWASP-SM_003)''<br /> ''4.5.4 Testing for Exposed Session Variables (OWASP-SM-004)''<br /> ''4.5.5 Testing for CSRF (OWASP-SM-005)''<br /> ''4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)''<br /> ''4.6.3 Testing for Privilege Escalation (OWASP-AZ-003)''<br /> <br /> <br /> |-<br /> |'''A4 Insecure Direct Object Reference'''<br /> ||If data is from internal trusted sources, no data is sent.<br /> <br /> Or<br /> <br /> ''Render:''<br /> *Send indirect random access reference map value.<br /> ||Obtain data from internal, trusted sources.<br /> <br /> Or<br /> <br /> Obtain direct value from random access reference access map.<br /> ||Validate role is sufficient to create, read, update, or delete data.<br /> <br /> ||''4.6.1 Testing for Path Traversal (OWASP-AZ-001)''<br /> <br /> |-<br /> |'''A5 Cross Site Request Forgery'''<br /> ||''Pre-render:''<br /> *Validate user is authenticated<br /> *Validate role is sufficient for this view<br /> <br /> ''Render:''<br /> *Send CSRF token.<br /> *Set &quot;secure&quot; and &quot;HttpOnly&quot; flags for session cookies.<br /> ||<br /> *Validate CSRF token.<br /> *Validate role is sufficient to perform this action.<br /> *Validate role is sufficient.<br /> <br /> ''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.5.5 Testing for CSRF (OWASP-SM-005)''<br /> <br /> |-<br /> |'''A6 Security Misconfiguration'''<br /> ||Ensure web servers and application servers are hardened.<br /> <br /> PHP: Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension <br /> ||Ensure web servers and application servers are hardened <br /> <br /> XML: Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer. <br /> ||Ensure database servers are hardened <br /> <br /> ||''4.2.6 Analysis of Error Codes (OWASP-IG-006)''<br /> ''4.3.2 DB Listener Testing (OWASP-CM-002)''<br /> ''4.3.3 Infrastructure Configuration Management Testing (OWASP-CM-003)''<br /> ''4.3.4 Application Configuration Management Testing (OWASP-CM-004)''<br /> ''4.3.5 Testing for File Extensions Handling (OWASP-CM-005)''<br /> ''4.3.6 Old, Backup and Unreferenced Files (OWASP-CM-006)''<br /> ''4.3.7 Infrastructure and Application Admin Interfaces (OWASP-CM-007)''<br /> ''4.3.8 Testing for HTTP Methods and XST (OWASP-CM-008)''<br /> <br /> <br /> |-<br /> |'''A7 Insufficient Cryptographic Storage'''<br /> ||''Design:''<br /> *Use strong ciphers (AES 128 or better).<br /> *Use strong hashes (SHA 256 or better) with salts for passwords.<br /> *Protect keys more than any other asset.<br /> <br /> ''Render:''<br /> *Do not send keys or hashes to the browser.<br /> <br /> ||''Design:''<br /> *Use strong ciphers (AES 128 or better).<br /> *Use strong hashes (SHA 256 or better) with salts for passwords.<br /> *Protect keys more than any other asset.<br /> <br /> ''Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen. ''<br /> <br /> ''Tip: It is best to encrypt data on the application server, rather than the database server.''<br /> <br /> ||''Design:''<br /> <br /> ''Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being &quot;encrypted&quot; on disk. ''<br /> <br /> ||<br /> <br /> <br /> |-<br /> |'''A8 Failure to Restrict URL access'''<br /> ||''Design:''<br /> *Ensure all non-web data is outside the web root (logs, configuration, etc).<br /> *Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar.<br /> *Ensure every page requires a role, even if it is &quot;guest&quot;.<br /> <br /> ''Pre-render:''<br /> *Validate user is authenticated.<br /> *Validate role is sufficient to view secured URL.<br /> <br /> ''Render:''<br /> *Send CSRF token.<br /> ||<br /> *Validate user is authenticated.<br /> *Validate role is sufficient to perform secured action.<br /> *Validate CSRF token.<br /> <br /> ''Tip: It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming. ''<br /> <br /> ''Tip: Assume attackers '''will''' learn where &quot;hidden&quot; directories and &quot;random&quot; filenames are, so do not store these files in the web root, even if they are not directly linked.''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)''<br /> ''4.6.1 Testing for Path Traversal (OWASP-AZ-001)''<br /> ''4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)''<br /> <br /> |-<br /> |'''A9 Insufficient Transport Layer Protection'''<br /> ||<br /> *Use TLS 1.2 or later for all web communications.<br /> *Buy extended validation (EV) certificates for public web servers.<br /> <br /> ''Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.''<br /> ||<br /> *Mandate strong encrypted communications between web and database servers and any other servers or administrative users.<br /> ||<br /> *Mandate strong encrypted communications with application servers and any other servers or administrative users.<br /> <br /> ||''4.3.1 SSL/TLS Testing (OWASP-CM-001)''<br /> ''4.4.1 Credentials transport over an encrypted channel (OWASP-AT-001)''<br /> <br /> |-<br /> |'''A10 Unvalidated Redirects and Forwards'''<br /> ||<br /> *Design the app without URL redirection parameters.<br /> <br /> or<br /> <br /> ''Render:''<br /> *Use random indirect object references for redirection parameters.<br /> <br /> ||<br /> *Design the app without URL redirection parameters.<br /> <br /> or<br /> <br /> *Obtain direct redirection parameter from random indirect reference access map.<br /> *(LR) Positive validation of redirection parameter.<br /> *(NR) Java – Do not forward() requests as this prevents SSO access control mechanisms.<br /> <br /> ||*Validate role is sufficient to create, read, update, or delete data.<br /> <br /> ||<br /> <br /> |-<br /> |}<br /> <br /> = Authors and Primary Editors =<br /> <br /> Andrew van der Stock vanderaj[at]owasp.org<br /> <br /> Ismael Rocha Gonçalves ismaelrg[at]gmail.com<br /> <br /> Jorge Correa jacorream@gmail.com<br /> <br /> = Other Cheatsheets =<br /> {{Cheatsheet_Navigation}}<br /> <br /> [[Category:Cheatsheets]]</div>

Jorge Correa https://wiki.owasp.org/index.php?title=OWASP_Top_Ten_Cheat_Sheet&diff=137508 2012-10-10T23:58:48Z

<p>Jorge Correa: </p> <hr /> <div>= Introduction =<br /> <br /> The following is a developer-centric defensive cheat sheet for the [[OWASP Top Ten Project]]. It also presents a quick reference based on [[OWASP Testing Project]] to help how to identify the risks.<br /> <br /> = OWASP Top Ten Cheat Sheet =<br /> <br /> {| border=1<br /> | <br /> ||'''Presentation'''<br /> ||'''Controller'''<br /> ||'''Model'''<br /> ||'''Testing (OWASP Testing Guide V3)'''<br /> <br /> |-<br /> |'''A1 Injection'''<br /> ||<br /> <br /> ''Render:''<br /> *Set a correct content type<br /> *Set safe character set (UTF-8)<br /> *Set correct locale<br /> <br /> ''On Submit:''<br /> *Enforce input field type and lengths.<br /> *Validate fields and provide feedback.<br /> *Ensure option selects and radio contain only sent values.<br /> ||'''Canonicalize using correct character set'''<br /> '''Positive input validation using correct character set'''<br /> <br /> (NR) Negative input validation.<br /> (LR) Sanitize input.<br /> <br /> ''Tip: updating a negative list (such as looking for &quot;script&quot;, &quot;sCrIpT&quot;, &quot;ßCrîpt&quot;, etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of &quot;bad&quot; words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. ''<br /> ||*'''[https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet Parameterized queries]'''<br /> <br /> *Object relational model (Hibernate).<br /> *Active Record design pattern.<br /> *Stored procedures.<br /> <br /> *Escape mechanisms such as ESAPI's Encoder:<br /> **EncodeForLDAP()<br /> **Encoder.EncodeforOS()<br /> <br /> ''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization ''<br /> <br /> ||''4.8.5 SQL Injection (OWASP-DV-005)''<br /> ''4.8.6 LDAP Injection (OWASP-DV-006)''<br /> ''4.8.7 ORM Injection (OWASP-DV-007)''<br /> ''4.8.8 XML Injection (OWASP-DV-008)''<br /> ''4.8.9 SSI Injection (OWASP-DV-009)''<br /> ''4.8.10 XPath Injection (OWASP-DV-010)''<br /> ''4.8.11 IMAP/SMTP Injection (OWASP-DV-011)''<br /> ''4.8.12 Code Injection (OWASP-DV-012)''<br /> ''4.8.13 OS Commanding (OWASP-DV-013)''<br /> ''4.8.14 Buffer overflow (OWASP-DV-014)''<br /> <br /> <br /> |-<br /> |'''A2 XSS'''<br /> ||<br /> <br /> ''Render:''<br /> *Set correct content type<br /> *Set safe character set (UTF-8)<br /> *Set correct locale<br /> *Output encode all user data as per output context<br /> *Set input constraints<br /> <br /> ''On Submit:''<br /> *Enforce input field type and lengths.<br /> *Validate fields and provide feedback.<br /> *Ensure option selects and radio contain only sent values.<br /> ||'''Canonicalize using correct character set'''<br /> '''Positive input validation using correct character set'''<br /> <br /> (NR) Negative input validation <br /> (LR) Sanitize input <br /> <br /> ''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.''<br /> ||''Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.''<br /> <br /> ''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data''<br /> <br /> ||''4.8.1 Testing for Reflected Cross Site Scripting (OWASP-DV-001)''<br /> ''4.8.2 Testing for Stored Cross Site Scripting (OWASP-DV-002)''<br /> ''4.8.3 Testing for DOM based Cross Site Scripting (OWASP-DV-003)''<br /> ''4.8.4 Testing for Cross Site Flashing (OWASP-DV004)''<br /> <br /> <br /> |-<br /> |'''A3 Weak authentication and session management'''<br /> ||''Render:''<br /> *Validate user is authenticated.<br /> *Validate role is sufficient for this view.<br /> *Set &quot;secure&quot; and &quot;HttpOnly&quot; flags for session cookies.<br /> *Send CSRF token with forms.<br /> <br /> ||''Design:''<br /> *Only use inbuilt session management.<br /> *Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies.<br /> <br /> *Validate user is authenticated.<br /> *Validate role is sufficient to perform this action.<br /> *Validate CSRF token.<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ''Tip: Consider the use of a &quot;governor&quot; to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.''<br /> <br /> ||''4.4.2 Testing for user enumeration (OWASP-AT-002)''<br /> ''4.4.3 Testing for Guessable (Dictionary) User Account (OWASP-AT-003)''<br /> ''4.4.4 Brute Force Testing (OWASP-AT-004)''<br /> ''4.4.6 Testing for vulnerable remember password and pwd reset (OWASP-AT-006)''<br /> ''4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)''<br /> ''4.4.7 Testing for Logout and Browser Cache Management (OWASP-AT-007)''<br /> ''4.4.8 Testing for CAPTCHA (OWASP-AT-008)''<br /> ''4.4.9 Testing Multiple Factors Authentication (OWASP-AT-009)''<br /> ''4.4.10 Testing for Race Conditions (OWASP-AT-010)''<br /> ''4.5.1 Testing for Session Management Schema (OWASP-SM-001)''<br /> ''4.5.2 Testing for Cookies attributes (OWASP-SM-002)''<br /> ''4.5.3 Testing for Session Fixation (OWASP-SM_003)''<br /> ''4.5.4 Testing for Exposed Session Variables (OWASP-SM-004)''<br /> ''4.5.5 Testing for CSRF (OWASP-SM-005)''<br /> ''4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)''<br /> ''4.6.3 Testing for Privilege Escalation (OWASP-AZ-003)''<br /> <br /> <br /> |-<br /> |'''A4 Insecure Direct Object Reference'''<br /> ||If data is from internal trusted sources, no data is sent.<br /> <br /> Or<br /> <br /> ''Render:''<br /> *Send indirect random access reference map value.<br /> ||Obtain data from internal, trusted sources.<br /> <br /> Or<br /> <br /> Obtain direct value from random access reference access map.<br /> ||Validate role is sufficient to create, read, update, or delete data.<br /> <br /> ||''4.6.1 Testing for Path Traversal (OWASP-AZ-001)''<br /> <br /> |-<br /> |'''A5 Cross Site Request Forgery'''<br /> ||''Pre-render:''<br /> *Validate user is authenticated<br /> *Validate role is sufficient for this view<br /> <br /> ''Render:''<br /> *Send CSRF token.<br /> *Set &quot;secure&quot; and &quot;HttpOnly&quot; flags for session cookies.<br /> ||<br /> *Validate CSRF token.<br /> *Validate role is sufficient to perform this action.<br /> *Validate role is sufficient.<br /> <br /> ''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.5.5 Testing for CSRF (OWASP-SM-005)''<br /> <br /> |-<br /> |'''A6 Security Misconfiguration'''<br /> ||Ensure web servers and application servers are hardened.<br /> <br /> PHP: Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension <br /> ||Ensure web servers and application servers are hardened <br /> <br /> XML: Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer. <br /> ||Ensure database servers are hardened <br /> <br /> ||''4.2.6 Analysis of Error Codes (OWASP-IG-006)''<br /> ''4.3.2 DB Listener Testing (OWASP-CM-002)''<br /> ''4.3.3 Infrastructure Configuration Management Testing (OWASP-CM-003)''<br /> ''4.3.4 Application Configuration Management Testing (OWASP-CM-004)''<br /> ''4.3.5 Testing for File Extensions Handling (OWASP-CM-005)''<br /> ''4.3.6 Old, Backup and Unreferenced Files (OWASP-CM-006)''<br /> ''4.3.7 Infrastructure and Application Admin Interfaces (OWASP-CM-007)''<br /> ''4.3.8 Testing for HTTP Methods and XST (OWASP-CM-008)''<br /> <br /> <br /> |-<br /> |'''A7 Insufficient Cryptographic Storage'''<br /> ||''Design:''<br /> *Use strong ciphers (AES 128 or better).<br /> *Use strong hashes (SHA 256 or better) with salts for passwords.<br /> *Protect keys more than any other asset.<br /> <br /> ''Render:''<br /> *Do not send keys or hashes to the browser.<br /> <br /> ||''Design:''<br /> *Use strong ciphers (AES 128 or better).<br /> *Use strong hashes (SHA 256 or better) with salts for passwords.<br /> *Protect keys more than any other asset.<br /> <br /> ''Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen. ''<br /> <br /> ''Tip: It is best to encrypt data on the application server, rather than the database server.''<br /> <br /> ||''Design:''<br /> <br /> ''Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being &quot;encrypted&quot; on disk. ''<br /> <br /> ||<br /> <br /> <br /> |-<br /> |'''A8 Failure to Restrict URL access'''<br /> ||''Design:''<br /> *Ensure all non-web data is outside the web root (logs, configuration, etc).<br /> *Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar.<br /> *Ensure every page requires a role, even if it is &quot;guest&quot;.<br /> <br /> ''Pre-render:''<br /> *Validate user is authenticated.<br /> *Validate role is sufficient to view secured URL.<br /> <br /> ''Render:''<br /> *Send CSRF token.<br /> ||*Validate user is authenticated.<br /> *Validate role is sufficient to perform secured action.<br /> *Validate CSRF token.<br /> <br /> ''Tip: It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming. ''<br /> <br /> ''Tip: Assume attackers '''will''' learn where &quot;hidden&quot; directories and &quot;random&quot; filenames are, so do not store these files in the web root, even if they are not directly linked.''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)''<br /> ''4.6.1 Testing for Path Traversal (OWASP-AZ-001)''<br /> ''4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)''<br /> <br /> |-<br /> |'''A9 Insufficient Transport Layer Protection'''<br /> ||*Use TLS 1.2 or later for all web communications.<br /> *Buy extended validation (EV) certificates for public web servers.<br /> <br /> ''Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.''<br /> ||*Mandate strong encrypted communications between web and database servers and any other servers or administrative users.<br /> ||*Mandate strong encrypted communications with application servers and any other servers or administrative users.<br /> <br /> ||''4.3.1 SSL/TLS Testing (OWASP-CM-001)''<br /> ''4.4.1 Credentials transport over an encrypted channel (OWASP-AT-001)''<br /> <br /> |-<br /> |'''A10 Unvalidated Redirects and Forwards'''<br /> ||*Design the app without URL redirection parameters.<br /> <br /> or<br /> <br /> ''Render:''<br /> *Use random indirect object references for redirection parameters.<br /> <br /> ||*Design the app without URL redirection parameters.<br /> <br /> or<br /> <br /> *Obtain direct redirection parameter from random indirect reference access map.<br /> *(LR) Positive validation of redirection parameter.<br /> *(NR) Java – Do not forward() requests as this prevents SSO access control mechanisms.<br /> <br /> ||*Validate role is sufficient to create, read, update, or delete data.<br /> <br /> ||<br /> <br /> |-<br /> |}<br /> <br /> = Authors and Primary Editors =<br /> <br /> Andrew van der Stock vanderaj[at]owasp.org<br /> <br /> Ismael Rocha Gonçalves ismaelrg[at]gmail.com<br /> <br /> Jorge Correa jacorream@gmail.com<br /> <br /> = Other Cheatsheets =<br /> {{Cheatsheet_Navigation}}<br /> <br /> [[Category:Cheatsheets]]</div>

Jorge Correa https://wiki.owasp.org/index.php?title=OWASP_Top_Ten_Cheat_Sheet&diff=137507 2012-10-10T23:56:27Z

<p>Jorge Correa: </p> <hr /> <div>= Introduction =<br /> <br /> The following is a developer-centric defensive cheat sheet for the [[OWASP Top Ten Project]]. It also presents a quick reference based on [[OWASP Testing Project]] to help how to identify the risks.<br /> <br /> = OWASP Top Ten Cheat Sheet =<br /> <br /> {| border=1<br /> | <br /> ||'''Presentation'''<br /> ||'''Controller'''<br /> ||'''Model'''<br /> ||'''Testing (OWASP Testing Guide V3)'''<br /> <br /> |-<br /> |'''A1 Injection'''<br /> ||<br /> <br /> ''Render:''<br /> *Set a correct content type<br /> *Set safe character set (UTF-8)<br /> *Set correct locale<br /> <br /> ''On Submit:''<br /> *Enforce input field type and lengths.<br /> *Validate fields and provide feedback.<br /> *Ensure option selects and radio contain only sent values.<br /> ||'''Canonicalize using correct character set'''<br /> '''Positive input validation using correct character set'''<br /> <br /> (NR) Negative input validation.<br /> (LR) Sanitize input.<br /> <br /> ''Tip: updating a negative list (such as looking for &quot;script&quot;, &quot;sCrIpT&quot;, &quot;ßCrîpt&quot;, etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of &quot;bad&quot; words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. ''<br /> ||*'''[https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet Parameterized queries]'''<br /> <br /> *Object relational model (Hibernate).<br /> *Active Record design pattern.<br /> *Stored procedures.<br /> <br /> *Escape mechanisms such as ESAPI's Encoder:<br /> **EncodeForLDAP()<br /> **Encoder.EncodeforOS()<br /> <br /> ''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization ''<br /> <br /> ||''4.8.5 SQL Injection (OWASP-DV-005)''<br /> ''4.8.6 LDAP Injection (OWASP-DV-006)''<br /> ''4.8.7 ORM Injection (OWASP-DV-007)''<br /> ''4.8.8 XML Injection (OWASP-DV-008)''<br /> ''4.8.9 SSI Injection (OWASP-DV-009)''<br /> ''4.8.10 XPath Injection (OWASP-DV-010)''<br /> ''4.8.11 IMAP/SMTP Injection (OWASP-DV-011)''<br /> ''4.8.12 Code Injection (OWASP-DV-012)''<br /> ''4.8.13 OS Commanding (OWASP-DV-013)''<br /> ''4.8.14 Buffer overflow (OWASP-DV-014)''<br /> <br /> <br /> |-<br /> |'''A2 XSS'''<br /> ||<br /> <br /> ''Render:''<br /> *Set correct content type<br /> *Set safe character set (UTF-8)<br /> *Set correct locale<br /> *Output encode all user data as per output context<br /> *Set input constraints<br /> <br /> ''On Submit:''<br /> *Enforce input field type and lengths.<br /> *Validate fields and provide feedback.<br /> *Ensure option selects and radio contain only sent values.<br /> ||'''Canonicalize using correct character set'''<br /> '''Positive input validation using correct character set'''<br /> <br /> (NR) Negative input validation <br /> (LR) Sanitize input <br /> <br /> ''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.''<br /> ||''Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.''<br /> <br /> ''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data''<br /> <br /> ||''4.8.1 Testing for Reflected Cross Site Scripting (OWASP-DV-001)''<br /> ''4.8.2 Testing for Stored Cross Site Scripting (OWASP-DV-002)''<br /> ''4.8.3 Testing for DOM based Cross Site Scripting (OWASP-DV-003)''<br /> ''4.8.4 Testing for Cross Site Flashing (OWASP-DV004)''<br /> <br /> <br /> |-<br /> |'''A3 Weak authentication and session management'''<br /> ||''Render:''<br /> *Validate user is authenticated.<br /> *Validate role is sufficient for this view.<br /> *Set &quot;secure&quot; and &quot;HttpOnly&quot; flags for session cookies.<br /> *Send CSRF token with forms.<br /> <br /> ||''Design:''<br /> *Only use inbuilt session management.<br /> *Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies.<br /> <br /> *Validate user is authenticated.<br /> *Validate role is sufficient to perform this action.<br /> *Validate CSRF token.<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ''Tip: Consider the use of a &quot;governor&quot; to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.''<br /> <br /> ||''4.4.2 Testing for user enumeration (OWASP-AT-002)''<br /> ''4.4.3 Testing for Guessable (Dictionary) User Account (OWASP-AT-003)''<br /> ''4.4.4 Brute Force Testing (OWASP-AT-004)''<br /> ''4.4.6 Testing for vulnerable remember password and pwd reset (OWASP-AT-006)''<br /> ''4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)''<br /> ''4.4.7 Testing for Logout and Browser Cache Management (OWASP-AT-007)''<br /> ''4.4.8 Testing for CAPTCHA (OWASP-AT-008)''<br /> ''4.4.9 Testing Multiple Factors Authentication (OWASP-AT-009)''<br /> ''4.4.10 Testing for Race Conditions (OWASP-AT-010)''<br /> ''4.5.1 Testing for Session Management Schema (OWASP-SM-001)''<br /> ''4.5.2 Testing for Cookies attributes (OWASP-SM-002)''<br /> ''4.5.3 Testing for Session Fixation (OWASP-SM_003)''<br /> ''4.5.4 Testing for Exposed Session Variables (OWASP-SM-004)''<br /> ''4.5.5 Testing for CSRF (OWASP-SM-005)''<br /> ''4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)''<br /> ''4.6.3 Testing for Privilege Escalation (OWASP-AZ-003)''<br /> <br /> <br /> |-<br /> |'''A4 Insecure Direct Object Reference'''<br /> ||If data is from internal trusted sources, no data is sent.<br /> <br /> Or<br /> <br /> ''Render:''<br /> *Send indirect random access reference map value.<br /> ||Obtain data from internal, trusted sources.<br /> <br /> Or<br /> <br /> Obtain direct value from random access reference access map.<br /> ||Validate role is sufficient to create, read, update, or delete data.<br /> <br /> ||''4.6.1 Testing for Path Traversal (OWASP-AZ-001)''<br /> <br /> |-<br /> |'''A5 Cross Site Request Forgery'''<br /> ||''Pre-render:''<br /> *Validate user is authenticated<br /> *Validate role is sufficient for this view<br /> <br /> ''Render:''<br /> *Send CSRF token.<br /> *Set &quot;secure&quot; and &quot;HttpOnly&quot; flags for session cookies.<br /> ||*Validate CSRF token.<br /> *Validate role is sufficient to perform this action.<br /> *Validate role is sufficient.<br /> <br /> ''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.5.5 Testing for CSRF (OWASP-SM-005)''<br /> <br /> |-<br /> |'''A6 Security Misconfiguration'''<br /> ||Ensure web servers and application servers are hardened.<br /> <br /> PHP: Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension <br /> ||Ensure web servers and application servers are hardened <br /> <br /> XML: Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer. <br /> ||Ensure database servers are hardened <br /> <br /> ||''4.2.6 Analysis of Error Codes (OWASP-IG-006)''<br /> ''4.3.2 DB Listener Testing (OWASP-CM-002)''<br /> ''4.3.3 Infrastructure Configuration Management Testing (OWASP-CM-003)''<br /> ''4.3.4 Application Configuration Management Testing (OWASP-CM-004)''<br /> ''4.3.5 Testing for File Extensions Handling (OWASP-CM-005)''<br /> ''4.3.6 Old, Backup and Unreferenced Files (OWASP-CM-006)''<br /> ''4.3.7 Infrastructure and Application Admin Interfaces (OWASP-CM-007)''<br /> ''4.3.8 Testing for HTTP Methods and XST (OWASP-CM-008)''<br /> <br /> <br /> |-<br /> |'''A7 Insufficient Cryptographic Storage'''<br /> ||''Design:''<br /> *Use strong ciphers (AES 128 or better).<br /> *Use strong hashes (SHA 256 or better) with salts for passwords.<br /> *Protect keys more than any other asset.<br /> <br /> ''Render:''<br /> *Do not send keys or hashes to the browser.<br /> <br /> ||''Design:''<br /> *Use strong ciphers (AES 128 or better).<br /> *Use strong hashes (SHA 256 or better) with salts for passwords.<br /> *Protect keys more than any other asset.<br /> <br /> ''Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen. ''<br /> <br /> ''Tip: It is best to encrypt data on the application server, rather than the database server.''<br /> <br /> ||''Design:''<br /> <br /> ''Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being &quot;encrypted&quot; on disk. ''<br /> <br /> ||<br /> <br /> <br /> |-<br /> |'''A8 Failure to Restrict URL access'''<br /> ||''Design:''<br /> *Ensure all non-web data is outside the web root (logs, configuration, etc).<br /> *Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar.<br /> *Ensure every page requires a role, even if it is &quot;guest&quot;.<br /> <br /> ''Pre-render:''<br /> *Validate user is authenticated.<br /> *Validate role is sufficient to view secured URL.<br /> <br /> ''Render:''<br /> *Send CSRF token.<br /> ||*Validate user is authenticated.<br /> *Validate role is sufficient to perform secured action.<br /> *Validate CSRF token.<br /> <br /> ''Tip: It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming. ''<br /> <br /> ''Tip: Assume attackers '''will''' learn where &quot;hidden&quot; directories and &quot;random&quot; filenames are, so do not store these files in the web root, even if they are not directly linked.''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)''<br /> ''4.6.1 Testing for Path Traversal (OWASP-AZ-001)''<br /> ''4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)''<br /> <br /> |-<br /> |'''A9 Insufficient Transport Layer Protection'''<br /> ||*Use TLS 1.2 or later for all web communications.<br /> *Buy extended validation (EV) certificates for public web servers.<br /> <br /> ''Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.''<br /> ||*Mandate strong encrypted communications between web and database servers and any other servers or administrative users.<br /> ||*Mandate strong encrypted communications with application servers and any other servers or administrative users.<br /> <br /> ||''4.3.1 SSL/TLS Testing (OWASP-CM-001)''<br /> ''4.4.1 Credentials transport over an encrypted channel (OWASP-AT-001)''<br /> <br /> |-<br /> |'''A10 Unvalidated Redirects and Forwards'''<br /> ||*Design the app without URL redirection parameters.<br /> <br /> or<br /> <br /> ''Render:''<br /> *Use random indirect object references for redirection parameters.<br /> <br /> ||*Design the app without URL redirection parameters.<br /> <br /> or<br /> <br /> *Obtain direct redirection parameter from random indirect reference access map.<br /> *(LR) Positive validation of redirection parameter.<br /> *(NR) Java – Do not forward() requests as this prevents SSO access control mechanisms.<br /> <br /> ||*Validate role is sufficient to create, read, update, or delete data.<br /> <br /> ||<br /> <br /> |-<br /> |}<br /> <br /> = Authors and Primary Editors =<br /> <br /> Andrew van der Stock vanderaj[at]owasp.org<br /> <br /> Ismael Rocha Gonçalves ismaelrg[at]gmail.com<br /> <br /> Jorge Correa jacorream@gmail.com<br /> <br /> = Other Cheatsheets =<br /> {{Cheatsheet_Navigation}}<br /> <br /> [[Category:Cheatsheets]]</div>

Jorge Correa https://wiki.owasp.org/index.php?title=OWASP_Top_Ten_Cheat_Sheet&diff=137279 2012-10-08T20:52:51Z

<p>Jorge Correa: </p> <hr /> <div>= Introduction =<br /> <br /> The following is a developer-centric defensive cheat sheet for the [[OWASP Top Ten Project]]. It also presents a quick reference based on [[OWASP Testing Project]] to help how to identify the risks.<br /> <br /> = OWASP Top Ten Cheat Sheet =<br /> <br /> {| border=1<br /> | <br /> ||'''Presentation'''<br /> ||'''Controller'''<br /> ||'''Model'''<br /> ||'''Testing (OWASP Testing Guide V3)'''<br /> <br /> |-<br /> |'''A1 Injection'''<br /> ||<br /> <br /> ''Render:''<br /> *Set a correct content type<br /> *Set safe character set (UTF-8)<br /> *Set correct locale<br /> <br /> ''On Submit:''<br /> *Enforce input field type and lengths.<br /> *Validate fields and provide feedback.<br /> *Ensure option selects and radio contain only sent values.<br /> ||'''Canonicalize using correct character set'''<br /> '''Positive input validation using correct character set'''<br /> <br /> (NR) Negative input validation.<br /> (LR) Sanitize input.<br /> <br /> ''Tip: updating a negative list (such as looking for &quot;script&quot;, &quot;sCrIpT&quot;, &quot;ßCrîpt&quot;, etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of &quot;bad&quot; words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. ''<br /> ||*'''[https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet Parameterized queries]'''<br /> <br /> *Object relational model (Hibernate).<br /> *Active Record design pattern.<br /> *Stored procedures.<br /> <br /> *Escape mechanisms such as ESAPI's Encoder:<br /> **EncodeForLDAP()<br /> **Encoder.EncodeforOS()<br /> <br /> ''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization ''<br /> <br /> ||''4.8.5 SQL Injection (OWASP-DV-005)''<br /> ''4.8.6 LDAP Injection (OWASP-DV-006)''<br /> ''4.8.7 ORM Injection (OWASP-DV-007)''<br /> ''4.8.8 XML Injection (OWASP-DV-008)''<br /> ''4.8.9 SSI Injection (OWASP-DV-009)''<br /> ''4.8.10 XPath Injection (OWASP-DV-010)''<br /> ''4.8.11 IMAP/SMTP Injection (OWASP-DV-011)''<br /> ''4.8.12 Code Injection (OWASP-DV-012)''<br /> ''4.8.13 OS Commanding (OWASP-DV-013)''<br /> ''4.8.14 Buffer overflow (OWASP-DV-014)''<br /> <br /> <br /> |-<br /> |'''A2 XSS'''<br /> ||<br /> <br /> ''Render:''<br /> *Set correct content type<br /> *Set safe character set (UTF-8)<br /> *Set correct locale<br /> *Output encode all user data as per output context<br /> *Set input constraints<br /> <br /> ''On Submit:''<br /> *Enforce input field type and lengths.<br /> *Validate fields and provide feedback.<br /> *Ensure option selects and radio contain only sent values.<br /> ||'''Canonicalize using correct character set'''<br /> '''Positive input validation using correct character set'''<br /> <br /> (NR) Negative input validation <br /> (LR) Sanitize input <br /> <br /> ''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.''<br /> ||''Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.''<br /> <br /> ''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data''<br /> <br /> ||''4.8.1 Testing for Reflected Cross Site Scripting (OWASP-DV-001)''<br /> ''4.8.2 Testing for Stored Cross Site Scripting (OWASP-DV-002)''<br /> ''4.8.3 Testing for DOM based Cross Site Scripting (OWASP-DV-003)''<br /> ''4.8.4 Testing for Cross Site Flashing (OWASP-DV004)''<br /> <br /> <br /> |-<br /> |'''A3 Weak authentication and session management'''<br /> ||''Render:''<br /> *Validate user is authenticated.<br /> *Validate role is sufficient for this view.<br /> *Set &quot;secure&quot; and &quot;HttpOnly&quot; flags for session cookies.<br /> *Send CSRF token with forms.<br /> <br /> ||''Design:''<br /> *Only use inbuilt session management.<br /> *Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies.<br /> <br /> *Validate user is authenticated.<br /> *Validate role is sufficient to perform this action.<br /> *Validate CSRF token.<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ''Tip: Consider the use of a &quot;governor&quot; to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.''<br /> <br /> ||''4.4.2 Testing for user enumeration (OWASP-AT-002)''<br /> ''4.4.3 Testing for Guessable (Dictionary) User Account (OWASP-AT-003)''<br /> ''4.4.4 Brute Force Testing (OWASP-AT-004)''<br /> ''4.4.6 Testing for vulnerable remember password and pwd reset (OWASP-AT-006)''<br /> ''4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)''<br /> ''4.4.7 Testing for Logout and Browser Cache Management (OWASP-AT-007)''<br /> ''4.4.8 Testing for CAPTCHA (OWASP-AT-008)''<br /> ''4.4.9 Testing Multiple Factors Authentication (OWASP-AT-009)''<br /> ''4.4.10 Testing for Race Conditions (OWASP-AT-010)''<br /> ''4.5.1 Testing for Session Management Schema (OWASP-SM-001)''<br /> ''4.5.2 Testing for Cookies attributes (OWASP-SM-002)''<br /> ''4.5.3 Testing for Session Fixation (OWASP-SM_003)''<br /> ''4.5.4 Testing for Exposed Session Variables (OWASP-SM-004)''<br /> ''4.5.5 Testing for CSRF (OWASP-SM-005)''<br /> ''4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)''<br /> ''4.6.3 Testing for Privilege Escalation (OWASP-AZ-003)''<br /> <br /> <br /> |-<br /> |'''A4 Insecure Direct Object Reference'''<br /> ||'''If data is from internal trusted sources, no data is sent'''<br /> <br /> ''Or''<br /> <br /> ''Render:''<br /> *Send indirect random access reference map value.<br /> ||'''Obtain data from internal, trusted sources'''<br /> <br /> ''Or ''<br /> <br /> '''Obtain direct value from random access reference access map'''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.6.1 Testing for Path Traversal (OWASP-AZ-001)''<br /> <br /> |-<br /> |'''A5 Cross Site Request Forgery'''<br /> ||''Pre-render''<br /> Validate user is authenticated<br /> Validate role is sufficient for this view<br /> <br /> ''Render''<br /> '''Send CSRF token '''<br /> Set &quot;secure&quot; and &quot;HttpOnly&quot; flags for session cookies<br /> ||'''Validate CSRF token'''<br /> Validate role is sufficient to perform this action<br /> Validate role is sufficient <br /> <br /> ''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.5.5 Testing for CSRF (OWASP-SM-005)''<br /> <br /> |-<br /> |'''A6 Security Misconfiguration'''<br /> ||Ensure web servers and application servers are hardened<br /> <br /> PHP – Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension <br /> ||Ensure web servers and application servers are hardened <br /> <br /> XML – Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer. <br /> ||Ensure database servers are hardened <br /> <br /> ||''4.2.6 Analysis of Error Codes (OWASP-IG-006)''<br /> ''4.3.2 DB Listener Testing (OWASP-CM-002)''<br /> ''4.3.3 Infrastructure Configuration Management Testing (OWASP-CM-003)''<br /> ''4.3.4 Application Configuration Management Testing (OWASP-CM-004)''<br /> ''4.3.5 Testing for File Extensions Handling (OWASP-CM-005)''<br /> ''4.3.6 Old, Backup and Unreferenced Files (OWASP-CM-006)''<br /> ''4.3.7 Infrastructure and Application Admin Interfaces (OWASP-CM-007)''<br /> ''4.3.8 Testing for HTTP Methods and XST (OWASP-CM-008)''<br /> <br /> <br /> |-<br /> |'''A7 Insufficient Cryptographic Storage'''<br /> ||''Design''<br /> '''Use strong ciphers (AES 128 or better)'''<br /> '''Use strong hashes (SHA 256 or better) with salts for passwords'''<br /> '''Protect keys more than any other asset'''<br /> <br /> ''Render''<br /> Do not send keys or hashes to the browser<br /> <br /> ||''Design''<br /> '''Use strong ciphers (AES 128 or better)'''<br /> '''Use strong hashes (SHA 256 or better) with salts for passwords'''<br /> '''Protect keys more than any other asset'''<br /> <br /> ''Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen. ''<br /> <br /> ''Tip: It is best to encrypt data on the application server, rather than the database server.''<br /> <br /> ||''Design''<br /> <br /> ''Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being &quot;encrypted&quot; on disk. ''<br /> <br /> ||<br /> <br /> <br /> |-<br /> |'''A8 Failure to Restrict URL access'''<br /> ||''Design''<br /> '''Ensure all non-web data is outside the web root (logs, configuration, etc)'''<br /> '''Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar'''<br /> '''Ensure every page requires a role, even if it is &quot;guest&quot;'''<br /> '' ''<br /> ''Pre-render''<br /> '''Validate user is authenticated'''<br /> '''Validate role is sufficient to view secured URL'''<br /> <br /> ''Render''<br /> '''Send CSRF token '''<br /> ||'''Validate user is authenticated'''<br /> '''Validate role is sufficient to perform secured action'''<br /> '''Validate CSRF token'''<br /> <br /> ''Tip: It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming. ''<br /> <br /> ''Tip: Assume attackers '''will''' learn where &quot;hidden&quot; directories and &quot;random&quot; filenames are, so do not store these files in the web root, even if they are not directly linked.''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)''<br /> ''4.6.1 Testing for Path Traversal (OWASP-AZ-001)''<br /> ''4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)''<br /> <br /> |-<br /> |'''A9 Insufficient Transport Layer Protection'''<br /> ||Use TLS 1.2 or later for all web communications <br /> Buy extended validation (EV) certificates for public web servers<br /> <br /> ''Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.''<br /> ||Mandate strong encrypted communications between web and database servers and any other servers or administrative users<br /> ||Mandate strong encrypted communications with application servers and any other servers or administrative users<br /> <br /> ||''4.3.1 SSL/TLS Testing (OWASP-CM-001)''<br /> ''4.4.1 Credentials transport over an encrypted channel (OWASP-AT-001)''<br /> <br /> |-<br /> |'''A10 Unvalidated Redirects and Forwards'''<br /> ||'''Design the app without URL redirection parameters'''<br /> <br /> ''or''<br /> <br /> ''Render''<br /> Use random indirect object references for redirection parameters<br /> <br /> ||'''Design the app without URL redirection parameters'''<br /> <br /> ''or''<br /> <br /> Obtain direct redirection parameter from random indirect reference access map<br /> (LR) Positive validation of redirection parameter <br /> (NR) Java – Do not forward() requests as this prevents SSO access control mechanisms <br /> <br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||<br /> <br /> |-<br /> |}<br /> <br /> = Authors and Primary Editors =<br /> <br /> Andrew van der Stock vanderaj[at]owasp.org<br /> <br /> Ismael Rocha Gonçalves ismaelrg[at]gmail.com<br /> <br /> = Other Cheatsheets =<br /> {{Cheatsheet_Navigation}}<br /> <br /> [[Category:Cheatsheets]]</div>

Jorge Correa https://wiki.owasp.org/index.php?title=OWASP_Top_Ten_Cheat_Sheet&diff=137277 2012-10-08T20:39:23Z

<p>Jorge Correa: </p> <hr /> <div>= Introduction =<br /> <br /> The following is a developer-centric defensive cheat sheet for the [[OWASP Top Ten Project]]. It also presents a quick reference based on [[OWASP Testing Project]] to help how to identify the risks.<br /> <br /> = OWASP Top Ten Cheat Sheet =<br /> <br /> {| border=1<br /> | <br /> ||'''Presentation'''<br /> ||'''Controller'''<br /> ||'''Model'''<br /> ||'''Testing (OWASP Testing Guide V3)'''<br /> <br /> |-<br /> |'''A1 Injection'''<br /> ||<br /> <br /> ''Render:''<br /> *Set a correct content type<br /> *Set safe character set (UTF-8)<br /> *Set correct locale<br /> <br /> ''On Submit:''<br /> Enforce input field type and lengths <br /> Validate fields and provide feedback<br /> Ensure option selects and radio contain only sent values<br /> ||'''Canonicalize using correct character set'''<br /> '''Positive input validation using correct character set'''<br /> <br /> (NR) Negative input validation.<br /> (LR) Sanitize input.<br /> <br /> ''Tip: updating a negative list (such as looking for &quot;script&quot;, &quot;sCrIpT&quot;, &quot;ßCrîpt&quot;, etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of &quot;bad&quot; words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. ''<br /> ||*'''[https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet Parameterized queries]'''<br /> <br /> *Object relational model (Hibernate).<br /> *Active Record design pattern.<br /> *Stored procedures.<br /> <br /> *Escape mechanisms such as ESAPI's Encoder:<br /> **EncodeForLDAP()<br /> **Encoder.EncodeforOS()<br /> <br /> ''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization ''<br /> <br /> ||''4.8.5 SQL Injection (OWASP-DV-005)''<br /> ''4.8.6 LDAP Injection (OWASP-DV-006)''<br /> ''4.8.7 ORM Injection (OWASP-DV-007)''<br /> ''4.8.8 XML Injection (OWASP-DV-008)''<br /> ''4.8.9 SSI Injection (OWASP-DV-009)''<br /> ''4.8.10 XPath Injection (OWASP-DV-010)''<br /> ''4.8.11 IMAP/SMTP Injection (OWASP-DV-011)''<br /> ''4.8.12 Code Injection (OWASP-DV-012)''<br /> ''4.8.13 OS Commanding (OWASP-DV-013)''<br /> ''4.8.14 Buffer overflow (OWASP-DV-014)''<br /> <br /> <br /> |-<br /> |'''A2 XSS'''<br /> ||<br /> <br /> ''Render:''<br /> *Set correct content type<br /> *Set safe character set (UTF-8)<br /> *Set correct locale<br /> *Output encode all user data as per output context<br /> *Set input constraints<br /> <br /> ''On Submit''<br /> Enforce input field type and lengths<br /> Validate fields and provide feedback<br /> Ensure option selects and radio contain only sent values<br /> ||'''Canonicalize using correct character set'''<br /> '''Positive input validation using correct character set'''<br /> <br /> (NR) Negative input validation <br /> (LR) Sanitize input <br /> <br /> ''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.''<br /> ||''Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.''<br /> <br /> ''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data''<br /> <br /> ||''4.8.1 Testing for Reflected Cross Site Scripting (OWASP-DV-001)''<br /> ''4.8.2 Testing for Stored Cross Site Scripting (OWASP-DV-002)''<br /> ''4.8.3 Testing for DOM based Cross Site Scripting (OWASP-DV-003)''<br /> ''4.8.4 Testing for Cross Site Flashing (OWASP-DV004)''<br /> <br /> <br /> |-<br /> |'''A3 Weak authentication and session management'''<br /> ||''Render''<br /> '''Validate user is authenticated'''<br /> '''Validate role is sufficient for this view'''<br /> '''Set &quot;secure&quot; and &quot;HttpOnly&quot; flags for session cookies'''<br /> Send CSRF token with forms<br /> <br /> ||''Design''<br /> '''Only use inbuilt session management'''<br /> '''Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies'''<br /> <br /> '''Validate user is authenticated'''<br /> '''Validate role is sufficient to perform this action'''<br /> Validate CSRF token<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ''Tip: Consider the use of a &quot;governor&quot; to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.''<br /> <br /> ||''4.4.2 Testing for user enumeration (OWASP-AT-002)''<br /> ''4.4.3 Testing for Guessable (Dictionary) User Account (OWASP-AT-003)''<br /> ''4.4.4 Brute Force Testing (OWASP-AT-004)''<br /> ''4.4.6 Testing for vulnerable remember password and pwd reset (OWASP-AT-006)''<br /> ''4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)''<br /> ''4.4.7 Testing for Logout and Browser Cache Management (OWASP-AT-007)''<br /> ''4.4.8 Testing for CAPTCHA (OWASP-AT-008)''<br /> ''4.4.9 Testing Multiple Factors Authentication (OWASP-AT-009)''<br /> ''4.4.10 Testing for Race Conditions (OWASP-AT-010)''<br /> ''4.5.1 Testing for Session Management Schema (OWASP-SM-001)''<br /> ''4.5.2 Testing for Cookies attributes (OWASP-SM-002)''<br /> ''4.5.3 Testing for Session Fixation (OWASP-SM_003)''<br /> ''4.5.4 Testing for Exposed Session Variables (OWASP-SM-004)''<br /> ''4.5.5 Testing for CSRF (OWASP-SM-005)''<br /> ''4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)''<br /> ''4.6.3 Testing for Privilege Escalation (OWASP-AZ-003)''<br /> <br /> <br /> |-<br /> |'''A4 Insecure Direct Object Reference'''<br /> ||'''If data is from internal trusted sources, no data is sent'''<br /> <br /> ''Or''<br /> <br /> ''Render''<br /> '''Send indirect random access reference map value'''<br /> ||'''Obtain data from internal, trusted sources'''<br /> <br /> ''Or ''<br /> <br /> '''Obtain direct value from random access reference access map'''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.6.1 Testing for Path Traversal (OWASP-AZ-001)''<br /> <br /> |-<br /> |'''A5 Cross Site Request Forgery'''<br /> ||''Pre-render''<br /> Validate user is authenticated<br /> Validate role is sufficient for this view<br /> <br /> ''Render''<br /> '''Send CSRF token '''<br /> Set &quot;secure&quot; and &quot;HttpOnly&quot; flags for session cookies<br /> ||'''Validate CSRF token'''<br /> Validate role is sufficient to perform this action<br /> Validate role is sufficient <br /> <br /> ''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.5.5 Testing for CSRF (OWASP-SM-005)''<br /> <br /> |-<br /> |'''A6 Security Misconfiguration'''<br /> ||Ensure web servers and application servers are hardened<br /> <br /> PHP – Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension <br /> ||Ensure web servers and application servers are hardened <br /> <br /> XML – Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer. <br /> ||Ensure database servers are hardened <br /> <br /> ||''4.2.6 Analysis of Error Codes (OWASP-IG-006)''<br /> ''4.3.2 DB Listener Testing (OWASP-CM-002)''<br /> ''4.3.3 Infrastructure Configuration Management Testing (OWASP-CM-003)''<br /> ''4.3.4 Application Configuration Management Testing (OWASP-CM-004)''<br /> ''4.3.5 Testing for File Extensions Handling (OWASP-CM-005)''<br /> ''4.3.6 Old, Backup and Unreferenced Files (OWASP-CM-006)''<br /> ''4.3.7 Infrastructure and Application Admin Interfaces (OWASP-CM-007)''<br /> ''4.3.8 Testing for HTTP Methods and XST (OWASP-CM-008)''<br /> <br /> <br /> |-<br /> |'''A7 Insufficient Cryptographic Storage'''<br /> ||''Design''<br /> '''Use strong ciphers (AES 128 or better)'''<br /> '''Use strong hashes (SHA 256 or better) with salts for passwords'''<br /> '''Protect keys more than any other asset'''<br /> <br /> ''Render''<br /> Do not send keys or hashes to the browser<br /> <br /> ||''Design''<br /> '''Use strong ciphers (AES 128 or better)'''<br /> '''Use strong hashes (SHA 256 or better) with salts for passwords'''<br /> '''Protect keys more than any other asset'''<br /> <br /> ''Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen. ''<br /> <br /> ''Tip: It is best to encrypt data on the application server, rather than the database server.''<br /> <br /> ||''Design''<br /> <br /> ''Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being &quot;encrypted&quot; on disk. ''<br /> <br /> ||<br /> <br /> <br /> |-<br /> |'''A8 Failure to Restrict URL access'''<br /> ||''Design''<br /> '''Ensure all non-web data is outside the web root (logs, configuration, etc)'''<br /> '''Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar'''<br /> '''Ensure every page requires a role, even if it is &quot;guest&quot;'''<br /> '' ''<br /> ''Pre-render''<br /> '''Validate user is authenticated'''<br /> '''Validate role is sufficient to view secured URL'''<br /> <br /> ''Render''<br /> '''Send CSRF token '''<br /> ||'''Validate user is authenticated'''<br /> '''Validate role is sufficient to perform secured action'''<br /> '''Validate CSRF token'''<br /> <br /> ''Tip: It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming. ''<br /> <br /> ''Tip: Assume attackers '''will''' learn where &quot;hidden&quot; directories and &quot;random&quot; filenames are, so do not store these files in the web root, even if they are not directly linked.''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)''<br /> ''4.6.1 Testing for Path Traversal (OWASP-AZ-001)''<br /> ''4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)''<br /> <br /> |-<br /> |'''A9 Insufficient Transport Layer Protection'''<br /> ||Use TLS 1.2 or later for all web communications <br /> Buy extended validation (EV) certificates for public web servers<br /> <br /> ''Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.''<br /> ||Mandate strong encrypted communications between web and database servers and any other servers or administrative users<br /> ||Mandate strong encrypted communications with application servers and any other servers or administrative users<br /> <br /> ||''4.3.1 SSL/TLS Testing (OWASP-CM-001)''<br /> ''4.4.1 Credentials transport over an encrypted channel (OWASP-AT-001)''<br /> <br /> |-<br /> |'''A10 Unvalidated Redirects and Forwards'''<br /> ||'''Design the app without URL redirection parameters'''<br /> <br /> ''or''<br /> <br /> ''Render''<br /> Use random indirect object references for redirection parameters<br /> <br /> ||'''Design the app without URL redirection parameters'''<br /> <br /> ''or''<br /> <br /> Obtain direct redirection parameter from random indirect reference access map<br /> (LR) Positive validation of redirection parameter <br /> (NR) Java – Do not forward() requests as this prevents SSO access control mechanisms <br /> <br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||<br /> <br /> |-<br /> |}<br /> <br /> = Authors and Primary Editors =<br /> <br /> Andrew van der Stock vanderaj[at]owasp.org<br /> <br /> Ismael Rocha Gonçalves ismaelrg[at]gmail.com<br /> <br /> = Other Cheatsheets =<br /> {{Cheatsheet_Navigation}}<br /> <br /> [[Category:Cheatsheets]]</div>

Jorge Correa https://wiki.owasp.org/index.php?title=OWASP_Top_Ten_Cheat_Sheet&diff=137275 2012-10-08T20:34:25Z

<p>Jorge Correa: </p> <hr /> <div>= Introduction =<br /> <br /> The following is a developer-centric defensive cheat sheet for the [[OWASP Top Ten Project]]. It also presents a quick reference based on [[OWASP Testing Project]] to help how to identify the risks.<br /> <br /> = OWASP Top Ten Cheat Sheet =<br /> <br /> {| border=1<br /> | <br /> ||'''Presentation'''<br /> ||'''Controller'''<br /> ||'''Model'''<br /> ||'''Testing (OWASP Testing Guide V3)'''<br /> <br /> |-<br /> |'''A1 Injection'''<br /> ||<br /> <br /> ''Render:''<br /> Set a correct content type<br /> Set safe character set (UTF-8)<br /> Set correct locale<br /> <br /> ''On Submit:''<br /> Enforce input field type and lengths <br /> Validate fields and provide feedback<br /> Ensure option selects and radio contain only sent values<br /> ||'''Canonicalize using correct character set'''<br /> '''Positive input validation using correct character set'''<br /> <br /> (NR) Negative input validation.<br /> (LR) Sanitize input.<br /> <br /> ''Tip: updating a negative list (such as looking for &quot;script&quot;, &quot;sCrIpT&quot;, &quot;ßCrîpt&quot;, etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of &quot;bad&quot; words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. ''<br /> ||*'''[https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet Parameterized queries]'''<br /> <br /> *Object relational model (Hibernate).<br /> *Active Record design pattern.<br /> *Stored procedures.<br /> <br /> *Escape mechanisms such as ESAPI's Encoder:<br /> **EncodeForLDAP()<br /> **Encoder.EncodeforOS()<br /> <br /> ''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization ''<br /> <br /> ||''4.8.5 SQL Injection (OWASP-DV-005)''<br /> ''4.8.6 LDAP Injection (OWASP-DV-006)''<br /> ''4.8.7 ORM Injection (OWASP-DV-007)''<br /> ''4.8.8 XML Injection (OWASP-DV-008)''<br /> ''4.8.9 SSI Injection (OWASP-DV-009)''<br /> ''4.8.10 XPath Injection (OWASP-DV-010)''<br /> ''4.8.11 IMAP/SMTP Injection (OWASP-DV-011)''<br /> ''4.8.12 Code Injection (OWASP-DV-012)''<br /> ''4.8.13 OS Commanding (OWASP-DV-013)''<br /> ''4.8.14 Buffer overflow (OWASP-DV-014)''<br /> <br /> <br /> |-<br /> |'''A2 XSS'''<br /> ||<br /> <br /> ''Render''<br /> '''Set correct content type'''<br /> '''Set safe character set (UTF-8) '''<br /> '''Set correct locale'''<br /> '''Output encode all user data as per output context'''<br /> '''Set input constraints '''<br /> <br /> ''On Submit''<br /> Enforce input field type and lengths<br /> Validate fields and provide feedback<br /> Ensure option selects and radio contain only sent values<br /> ||'''Canonicalize using correct character set'''<br /> '''Positive input validation using correct character set'''<br /> <br /> (NR) Negative input validation <br /> (LR) Sanitize input <br /> <br /> ''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.''<br /> ||''Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.''<br /> <br /> ''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data''<br /> <br /> ||''4.8.1 Testing for Reflected Cross Site Scripting (OWASP-DV-001)''<br /> ''4.8.2 Testing for Stored Cross Site Scripting (OWASP-DV-002)''<br /> ''4.8.3 Testing for DOM based Cross Site Scripting (OWASP-DV-003)''<br /> ''4.8.4 Testing for Cross Site Flashing (OWASP-DV004)''<br /> <br /> <br /> |-<br /> |'''A3 Weak authentication and session management'''<br /> ||''Render''<br /> '''Validate user is authenticated'''<br /> '''Validate role is sufficient for this view'''<br /> '''Set &quot;secure&quot; and &quot;HttpOnly&quot; flags for session cookies'''<br /> Send CSRF token with forms<br /> <br /> ||''Design''<br /> '''Only use inbuilt session management'''<br /> '''Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies'''<br /> <br /> '''Validate user is authenticated'''<br /> '''Validate role is sufficient to perform this action'''<br /> Validate CSRF token<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ''Tip: Consider the use of a &quot;governor&quot; to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.''<br /> <br /> ||''4.4.2 Testing for user enumeration (OWASP-AT-002)''<br /> ''4.4.3 Testing for Guessable (Dictionary) User Account (OWASP-AT-003)''<br /> ''4.4.4 Brute Force Testing (OWASP-AT-004)''<br /> ''4.4.6 Testing for vulnerable remember password and pwd reset (OWASP-AT-006)''<br /> ''4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)''<br /> ''4.4.7 Testing for Logout and Browser Cache Management (OWASP-AT-007)''<br /> ''4.4.8 Testing for CAPTCHA (OWASP-AT-008)''<br /> ''4.4.9 Testing Multiple Factors Authentication (OWASP-AT-009)''<br /> ''4.4.10 Testing for Race Conditions (OWASP-AT-010)''<br /> ''4.5.1 Testing for Session Management Schema (OWASP-SM-001)''<br /> ''4.5.2 Testing for Cookies attributes (OWASP-SM-002)''<br /> ''4.5.3 Testing for Session Fixation (OWASP-SM_003)''<br /> ''4.5.4 Testing for Exposed Session Variables (OWASP-SM-004)''<br /> ''4.5.5 Testing for CSRF (OWASP-SM-005)''<br /> ''4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)''<br /> ''4.6.3 Testing for Privilege Escalation (OWASP-AZ-003)''<br /> <br /> <br /> |-<br /> |'''A4 Insecure Direct Object Reference'''<br /> ||'''If data is from internal trusted sources, no data is sent'''<br /> <br /> ''Or''<br /> <br /> ''Render''<br /> '''Send indirect random access reference map value'''<br /> ||'''Obtain data from internal, trusted sources'''<br /> <br /> ''Or ''<br /> <br /> '''Obtain direct value from random access reference access map'''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.6.1 Testing for Path Traversal (OWASP-AZ-001)''<br /> <br /> |-<br /> |'''A5 Cross Site Request Forgery'''<br /> ||''Pre-render''<br /> Validate user is authenticated<br /> Validate role is sufficient for this view<br /> <br /> ''Render''<br /> '''Send CSRF token '''<br /> Set &quot;secure&quot; and &quot;HttpOnly&quot; flags for session cookies<br /> ||'''Validate CSRF token'''<br /> Validate role is sufficient to perform this action<br /> Validate role is sufficient <br /> <br /> ''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.5.5 Testing for CSRF (OWASP-SM-005)''<br /> <br /> |-<br /> |'''A6 Security Misconfiguration'''<br /> ||Ensure web servers and application servers are hardened<br /> <br /> PHP – Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension <br /> ||Ensure web servers and application servers are hardened <br /> <br /> XML – Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer. <br /> ||Ensure database servers are hardened <br /> <br /> ||''4.2.6 Analysis of Error Codes (OWASP-IG-006)''<br /> ''4.3.2 DB Listener Testing (OWASP-CM-002)''<br /> ''4.3.3 Infrastructure Configuration Management Testing (OWASP-CM-003)''<br /> ''4.3.4 Application Configuration Management Testing (OWASP-CM-004)''<br /> ''4.3.5 Testing for File Extensions Handling (OWASP-CM-005)''<br /> ''4.3.6 Old, Backup and Unreferenced Files (OWASP-CM-006)''<br /> ''4.3.7 Infrastructure and Application Admin Interfaces (OWASP-CM-007)''<br /> ''4.3.8 Testing for HTTP Methods and XST (OWASP-CM-008)''<br /> <br /> <br /> |-<br /> |'''A7 Insufficient Cryptographic Storage'''<br /> ||''Design''<br /> '''Use strong ciphers (AES 128 or better)'''<br /> '''Use strong hashes (SHA 256 or better) with salts for passwords'''<br /> '''Protect keys more than any other asset'''<br /> <br /> ''Render''<br /> Do not send keys or hashes to the browser<br /> <br /> ||''Design''<br /> '''Use strong ciphers (AES 128 or better)'''<br /> '''Use strong hashes (SHA 256 or better) with salts for passwords'''<br /> '''Protect keys more than any other asset'''<br /> <br /> ''Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen. ''<br /> <br /> ''Tip: It is best to encrypt data on the application server, rather than the database server.''<br /> <br /> ||''Design''<br /> <br /> ''Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being &quot;encrypted&quot; on disk. ''<br /> <br /> ||<br /> <br /> <br /> |-<br /> |'''A8 Failure to Restrict URL access'''<br /> ||''Design''<br /> '''Ensure all non-web data is outside the web root (logs, configuration, etc)'''<br /> '''Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar'''<br /> '''Ensure every page requires a role, even if it is &quot;guest&quot;'''<br /> '' ''<br /> ''Pre-render''<br /> '''Validate user is authenticated'''<br /> '''Validate role is sufficient to view secured URL'''<br /> <br /> ''Render''<br /> '''Send CSRF token '''<br /> ||'''Validate user is authenticated'''<br /> '''Validate role is sufficient to perform secured action'''<br /> '''Validate CSRF token'''<br /> <br /> ''Tip: It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming. ''<br /> <br /> ''Tip: Assume attackers '''will''' learn where &quot;hidden&quot; directories and &quot;random&quot; filenames are, so do not store these files in the web root, even if they are not directly linked.''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)''<br /> ''4.6.1 Testing for Path Traversal (OWASP-AZ-001)''<br /> ''4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)''<br /> <br /> |-<br /> |'''A9 Insufficient Transport Layer Protection'''<br /> ||Use TLS 1.2 or later for all web communications <br /> Buy extended validation (EV) certificates for public web servers<br /> <br /> ''Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.''<br /> ||Mandate strong encrypted communications between web and database servers and any other servers or administrative users<br /> ||Mandate strong encrypted communications with application servers and any other servers or administrative users<br /> <br /> ||''4.3.1 SSL/TLS Testing (OWASP-CM-001)''<br /> ''4.4.1 Credentials transport over an encrypted channel (OWASP-AT-001)''<br /> <br /> |-<br /> |'''A10 Unvalidated Redirects and Forwards'''<br /> ||'''Design the app without URL redirection parameters'''<br /> <br /> ''or''<br /> <br /> ''Render''<br /> Use random indirect object references for redirection parameters<br /> <br /> ||'''Design the app without URL redirection parameters'''<br /> <br /> ''or''<br /> <br /> Obtain direct redirection parameter from random indirect reference access map<br /> (LR) Positive validation of redirection parameter <br /> (NR) Java – Do not forward() requests as this prevents SSO access control mechanisms <br /> <br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||<br /> <br /> |-<br /> |}<br /> <br /> = Authors and Primary Editors =<br /> <br /> Andrew van der Stock vanderaj[at]owasp.org<br /> <br /> Ismael Rocha Gonçalves ismaelrg[at]gmail.com<br /> <br /> = Other Cheatsheets =<br /> {{Cheatsheet_Navigation}}<br /> <br /> [[Category:Cheatsheets]]</div>

Jorge Correa https://wiki.owasp.org/index.php?title=OWASP_Top_Ten_Cheat_Sheet&diff=137274 2012-10-08T20:33:06Z

<p>Jorge Correa: </p> <hr /> <div>= Introduction =<br /> <br /> The following is a developer-centric defensive cheat sheet for the [[OWASP Top Ten Project]]. It also presents a quick reference based on [[OWASP Testing Project]] to help how to identify the risks.<br /> <br /> = OWASP Top Ten Cheat Sheet =<br /> <br /> {| border=1<br /> | <br /> ||'''Presentation'''<br /> ||'''Controller'''<br /> ||'''Model'''<br /> ||'''Testing (OWASP Testing Guide V3)'''<br /> <br /> |-<br /> |'''A1 Injection'''<br /> ||<br /> <br /> ''Render:''<br /> Set a correct content type<br /> Set safe character set (UTF-8)<br /> Set correct locale<br /> <br /> ''On Submit:''<br /> Enforce input field type and lengths <br /> Validate fields and provide feedback<br /> Ensure option selects and radio contain only sent values<br /> ||'''Canonicalize using correct character set'''<br /> '''Positive input validation using correct character set'''<br /> <br /> (NR) Negative input validation.<br /> (LR) Sanitize input.<br /> <br /> ''Tip: updating a negative list (such as looking for &quot;script&quot;, &quot;sCrIpT&quot;, &quot;ßCrîpt&quot;, etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of &quot;bad&quot; words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. ''<br /> ||*'''[https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet Parameterized queries]'''<br /> <br /> *Object relational model (Hibernate).<br /> *Active Record design pattern.<br /> *Stored procedures.<br /> <br /> *Escape mechanisms such as:<br /> **ESAPI's Encoder<br /> **EncodeForLDAP()<br /> **Encoder.EncodeforOS()<br /> <br /> ''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization ''<br /> <br /> ||''4.8.5 SQL Injection (OWASP-DV-005)''<br /> ''4.8.6 LDAP Injection (OWASP-DV-006)''<br /> ''4.8.7 ORM Injection (OWASP-DV-007)''<br /> ''4.8.8 XML Injection (OWASP-DV-008)''<br /> ''4.8.9 SSI Injection (OWASP-DV-009)''<br /> ''4.8.10 XPath Injection (OWASP-DV-010)''<br /> ''4.8.11 IMAP/SMTP Injection (OWASP-DV-011)''<br /> ''4.8.12 Code Injection (OWASP-DV-012)''<br /> ''4.8.13 OS Commanding (OWASP-DV-013)''<br /> ''4.8.14 Buffer overflow (OWASP-DV-014)''<br /> <br /> <br /> |-<br /> |'''A2 XSS'''<br /> ||<br /> <br /> ''Render''<br /> '''Set correct content type'''<br /> '''Set safe character set (UTF-8) '''<br /> '''Set correct locale'''<br /> '''Output encode all user data as per output context'''<br /> '''Set input constraints '''<br /> <br /> ''On Submit''<br /> Enforce input field type and lengths<br /> Validate fields and provide feedback<br /> Ensure option selects and radio contain only sent values<br /> ||'''Canonicalize using correct character set'''<br /> '''Positive input validation using correct character set'''<br /> <br /> (NR) Negative input validation <br /> (LR) Sanitize input <br /> <br /> ''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.''<br /> ||''Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.''<br /> <br /> ''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data''<br /> <br /> ||''4.8.1 Testing for Reflected Cross Site Scripting (OWASP-DV-001)''<br /> ''4.8.2 Testing for Stored Cross Site Scripting (OWASP-DV-002)''<br /> ''4.8.3 Testing for DOM based Cross Site Scripting (OWASP-DV-003)''<br /> ''4.8.4 Testing for Cross Site Flashing (OWASP-DV004)''<br /> <br /> <br /> |-<br /> |'''A3 Weak authentication and session management'''<br /> ||''Render''<br /> '''Validate user is authenticated'''<br /> '''Validate role is sufficient for this view'''<br /> '''Set &quot;secure&quot; and &quot;HttpOnly&quot; flags for session cookies'''<br /> Send CSRF token with forms<br /> <br /> ||''Design''<br /> '''Only use inbuilt session management'''<br /> '''Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies'''<br /> <br /> '''Validate user is authenticated'''<br /> '''Validate role is sufficient to perform this action'''<br /> Validate CSRF token<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ''Tip: Consider the use of a &quot;governor&quot; to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.''<br /> <br /> ||''4.4.2 Testing for user enumeration (OWASP-AT-002)''<br /> ''4.4.3 Testing for Guessable (Dictionary) User Account (OWASP-AT-003)''<br /> ''4.4.4 Brute Force Testing (OWASP-AT-004)''<br /> ''4.4.6 Testing for vulnerable remember password and pwd reset (OWASP-AT-006)''<br /> ''4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)''<br /> ''4.4.7 Testing for Logout and Browser Cache Management (OWASP-AT-007)''<br /> ''4.4.8 Testing for CAPTCHA (OWASP-AT-008)''<br /> ''4.4.9 Testing Multiple Factors Authentication (OWASP-AT-009)''<br /> ''4.4.10 Testing for Race Conditions (OWASP-AT-010)''<br /> ''4.5.1 Testing for Session Management Schema (OWASP-SM-001)''<br /> ''4.5.2 Testing for Cookies attributes (OWASP-SM-002)''<br /> ''4.5.3 Testing for Session Fixation (OWASP-SM_003)''<br /> ''4.5.4 Testing for Exposed Session Variables (OWASP-SM-004)''<br /> ''4.5.5 Testing for CSRF (OWASP-SM-005)''<br /> ''4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)''<br /> ''4.6.3 Testing for Privilege Escalation (OWASP-AZ-003)''<br /> <br /> <br /> |-<br /> |'''A4 Insecure Direct Object Reference'''<br /> ||'''If data is from internal trusted sources, no data is sent'''<br /> <br /> ''Or''<br /> <br /> ''Render''<br /> '''Send indirect random access reference map value'''<br /> ||'''Obtain data from internal, trusted sources'''<br /> <br /> ''Or ''<br /> <br /> '''Obtain direct value from random access reference access map'''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.6.1 Testing for Path Traversal (OWASP-AZ-001)''<br /> <br /> |-<br /> |'''A5 Cross Site Request Forgery'''<br /> ||''Pre-render''<br /> Validate user is authenticated<br /> Validate role is sufficient for this view<br /> <br /> ''Render''<br /> '''Send CSRF token '''<br /> Set &quot;secure&quot; and &quot;HttpOnly&quot; flags for session cookies<br /> ||'''Validate CSRF token'''<br /> Validate role is sufficient to perform this action<br /> Validate role is sufficient <br /> <br /> ''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.5.5 Testing for CSRF (OWASP-SM-005)''<br /> <br /> |-<br /> |'''A6 Security Misconfiguration'''<br /> ||Ensure web servers and application servers are hardened<br /> <br /> PHP – Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension <br /> ||Ensure web servers and application servers are hardened <br /> <br /> XML – Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer. <br /> ||Ensure database servers are hardened <br /> <br /> ||''4.2.6 Analysis of Error Codes (OWASP-IG-006)''<br /> ''4.3.2 DB Listener Testing (OWASP-CM-002)''<br /> ''4.3.3 Infrastructure Configuration Management Testing (OWASP-CM-003)''<br /> ''4.3.4 Application Configuration Management Testing (OWASP-CM-004)''<br /> ''4.3.5 Testing for File Extensions Handling (OWASP-CM-005)''<br /> ''4.3.6 Old, Backup and Unreferenced Files (OWASP-CM-006)''<br /> ''4.3.7 Infrastructure and Application Admin Interfaces (OWASP-CM-007)''<br /> ''4.3.8 Testing for HTTP Methods and XST (OWASP-CM-008)''<br /> <br /> <br /> |-<br /> |'''A7 Insufficient Cryptographic Storage'''<br /> ||''Design''<br /> '''Use strong ciphers (AES 128 or better)'''<br /> '''Use strong hashes (SHA 256 or better) with salts for passwords'''<br /> '''Protect keys more than any other asset'''<br /> <br /> ''Render''<br /> Do not send keys or hashes to the browser<br /> <br /> ||''Design''<br /> '''Use strong ciphers (AES 128 or better)'''<br /> '''Use strong hashes (SHA 256 or better) with salts for passwords'''<br /> '''Protect keys more than any other asset'''<br /> <br /> ''Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen. ''<br /> <br /> ''Tip: It is best to encrypt data on the application server, rather than the database server.''<br /> <br /> ||''Design''<br /> <br /> ''Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being &quot;encrypted&quot; on disk. ''<br /> <br /> ||<br /> <br /> <br /> |-<br /> |'''A8 Failure to Restrict URL access'''<br /> ||''Design''<br /> '''Ensure all non-web data is outside the web root (logs, configuration, etc)'''<br /> '''Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar'''<br /> '''Ensure every page requires a role, even if it is &quot;guest&quot;'''<br /> '' ''<br /> ''Pre-render''<br /> '''Validate user is authenticated'''<br /> '''Validate role is sufficient to view secured URL'''<br /> <br /> ''Render''<br /> '''Send CSRF token '''<br /> ||'''Validate user is authenticated'''<br /> '''Validate role is sufficient to perform secured action'''<br /> '''Validate CSRF token'''<br /> <br /> ''Tip: It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming. ''<br /> <br /> ''Tip: Assume attackers '''will''' learn where &quot;hidden&quot; directories and &quot;random&quot; filenames are, so do not store these files in the web root, even if they are not directly linked.''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)''<br /> ''4.6.1 Testing for Path Traversal (OWASP-AZ-001)''<br /> ''4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)''<br /> <br /> |-<br /> |'''A9 Insufficient Transport Layer Protection'''<br /> ||Use TLS 1.2 or later for all web communications <br /> Buy extended validation (EV) certificates for public web servers<br /> <br /> ''Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.''<br /> ||Mandate strong encrypted communications between web and database servers and any other servers or administrative users<br /> ||Mandate strong encrypted communications with application servers and any other servers or administrative users<br /> <br /> ||''4.3.1 SSL/TLS Testing (OWASP-CM-001)''<br /> ''4.4.1 Credentials transport over an encrypted channel (OWASP-AT-001)''<br /> <br /> |-<br /> |'''A10 Unvalidated Redirects and Forwards'''<br /> ||'''Design the app without URL redirection parameters'''<br /> <br /> ''or''<br /> <br /> ''Render''<br /> Use random indirect object references for redirection parameters<br /> <br /> ||'''Design the app without URL redirection parameters'''<br /> <br /> ''or''<br /> <br /> Obtain direct redirection parameter from random indirect reference access map<br /> (LR) Positive validation of redirection parameter <br /> (NR) Java – Do not forward() requests as this prevents SSO access control mechanisms <br /> <br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||<br /> <br /> |-<br /> |}<br /> <br /> = Authors and Primary Editors =<br /> <br /> Andrew van der Stock vanderaj[at]owasp.org<br /> <br /> Ismael Rocha Gonçalves ismaelrg[at]gmail.com<br /> <br /> = Other Cheatsheets =<br /> {{Cheatsheet_Navigation}}<br /> <br /> [[Category:Cheatsheets]]</div>

Jorge Correa https://wiki.owasp.org/index.php?title=OWASP_Top_Ten_Cheat_Sheet&diff=137273 2012-10-08T20:32:06Z

<p>Jorge Correa: </p> <hr /> <div>= Introduction =<br /> <br /> The following is a developer-centric defensive cheat sheet for the [[OWASP Top Ten Project]]. It also presents a quick reference based on [[OWASP Testing Project]] to help how to identify the risks.<br /> <br /> = OWASP Top Ten Cheat Sheet =<br /> <br /> {| border=1<br /> | <br /> ||'''Presentation'''<br /> ||'''Controller'''<br /> ||'''Model'''<br /> ||'''Testing (OWASP Testing Guide V3)'''<br /> <br /> |-<br /> |'''A1 Injection'''<br /> ||<br /> <br /> ''Render:''<br /> Set a correct content type<br /> Set safe character set (UTF-8)<br /> Set correct locale<br /> <br /> ''On Submit:''<br /> Enforce input field type and lengths <br /> Validate fields and provide feedback<br /> Ensure option selects and radio contain only sent values<br /> ||'''Canonicalize using correct character set'''<br /> '''Positive input validation using correct character set'''<br /> <br /> (NR) Negative input validation.<br /> (LR) Sanitize input.<br /> <br /> ''Tip: updating a negative list (such as looking for &quot;script&quot;, &quot;sCrIpT&quot;, &quot;ßCrîpt&quot;, etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of &quot;bad&quot; words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. ''<br /> ||'''[https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet Parameterized queries]'''<br /> <br /> *Object relational model (Hibernate).<br /> *Active Record design pattern.<br /> *Stored procedures.<br /> <br /> Escape mechanisms such as ESAPI's Encoder, EncodeForLDAP() or Encoder.EncodeforOS()<br /> <br /> ''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization ''<br /> <br /> ||''4.8.5 SQL Injection (OWASP-DV-005)''<br /> ''4.8.6 LDAP Injection (OWASP-DV-006)''<br /> ''4.8.7 ORM Injection (OWASP-DV-007)''<br /> ''4.8.8 XML Injection (OWASP-DV-008)''<br /> ''4.8.9 SSI Injection (OWASP-DV-009)''<br /> ''4.8.10 XPath Injection (OWASP-DV-010)''<br /> ''4.8.11 IMAP/SMTP Injection (OWASP-DV-011)''<br /> ''4.8.12 Code Injection (OWASP-DV-012)''<br /> ''4.8.13 OS Commanding (OWASP-DV-013)''<br /> ''4.8.14 Buffer overflow (OWASP-DV-014)''<br /> <br /> <br /> |-<br /> |'''A2 XSS'''<br /> ||<br /> <br /> ''Render''<br /> '''Set correct content type'''<br /> '''Set safe character set (UTF-8) '''<br /> '''Set correct locale'''<br /> '''Output encode all user data as per output context'''<br /> '''Set input constraints '''<br /> <br /> ''On Submit''<br /> Enforce input field type and lengths<br /> Validate fields and provide feedback<br /> Ensure option selects and radio contain only sent values<br /> ||'''Canonicalize using correct character set'''<br /> '''Positive input validation using correct character set'''<br /> <br /> (NR) Negative input validation <br /> (LR) Sanitize input <br /> <br /> ''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.''<br /> ||''Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.''<br /> <br /> ''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data''<br /> <br /> ||''4.8.1 Testing for Reflected Cross Site Scripting (OWASP-DV-001)''<br /> ''4.8.2 Testing for Stored Cross Site Scripting (OWASP-DV-002)''<br /> ''4.8.3 Testing for DOM based Cross Site Scripting (OWASP-DV-003)''<br /> ''4.8.4 Testing for Cross Site Flashing (OWASP-DV004)''<br /> <br /> <br /> |-<br /> |'''A3 Weak authentication and session management'''<br /> ||''Render''<br /> '''Validate user is authenticated'''<br /> '''Validate role is sufficient for this view'''<br /> '''Set &quot;secure&quot; and &quot;HttpOnly&quot; flags for session cookies'''<br /> Send CSRF token with forms<br /> <br /> ||''Design''<br /> '''Only use inbuilt session management'''<br /> '''Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies'''<br /> <br /> '''Validate user is authenticated'''<br /> '''Validate role is sufficient to perform this action'''<br /> Validate CSRF token<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ''Tip: Consider the use of a &quot;governor&quot; to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.''<br /> <br /> ||''4.4.2 Testing for user enumeration (OWASP-AT-002)''<br /> ''4.4.3 Testing for Guessable (Dictionary) User Account (OWASP-AT-003)''<br /> ''4.4.4 Brute Force Testing (OWASP-AT-004)''<br /> ''4.4.6 Testing for vulnerable remember password and pwd reset (OWASP-AT-006)''<br /> ''4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)''<br /> ''4.4.7 Testing for Logout and Browser Cache Management (OWASP-AT-007)''<br /> ''4.4.8 Testing for CAPTCHA (OWASP-AT-008)''<br /> ''4.4.9 Testing Multiple Factors Authentication (OWASP-AT-009)''<br /> ''4.4.10 Testing for Race Conditions (OWASP-AT-010)''<br /> ''4.5.1 Testing for Session Management Schema (OWASP-SM-001)''<br /> ''4.5.2 Testing for Cookies attributes (OWASP-SM-002)''<br /> ''4.5.3 Testing for Session Fixation (OWASP-SM_003)''<br /> ''4.5.4 Testing for Exposed Session Variables (OWASP-SM-004)''<br /> ''4.5.5 Testing for CSRF (OWASP-SM-005)''<br /> ''4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)''<br /> ''4.6.3 Testing for Privilege Escalation (OWASP-AZ-003)''<br /> <br /> <br /> |-<br /> |'''A4 Insecure Direct Object Reference'''<br /> ||'''If data is from internal trusted sources, no data is sent'''<br /> <br /> ''Or''<br /> <br /> ''Render''<br /> '''Send indirect random access reference map value'''<br /> ||'''Obtain data from internal, trusted sources'''<br /> <br /> ''Or ''<br /> <br /> '''Obtain direct value from random access reference access map'''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.6.1 Testing for Path Traversal (OWASP-AZ-001)''<br /> <br /> |-<br /> |'''A5 Cross Site Request Forgery'''<br /> ||''Pre-render''<br /> Validate user is authenticated<br /> Validate role is sufficient for this view<br /> <br /> ''Render''<br /> '''Send CSRF token '''<br /> Set &quot;secure&quot; and &quot;HttpOnly&quot; flags for session cookies<br /> ||'''Validate CSRF token'''<br /> Validate role is sufficient to perform this action<br /> Validate role is sufficient <br /> <br /> ''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.5.5 Testing for CSRF (OWASP-SM-005)''<br /> <br /> |-<br /> |'''A6 Security Misconfiguration'''<br /> ||Ensure web servers and application servers are hardened<br /> <br /> PHP – Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension <br /> ||Ensure web servers and application servers are hardened <br /> <br /> XML – Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer. <br /> ||Ensure database servers are hardened <br /> <br /> ||''4.2.6 Analysis of Error Codes (OWASP-IG-006)''<br /> ''4.3.2 DB Listener Testing (OWASP-CM-002)''<br /> ''4.3.3 Infrastructure Configuration Management Testing (OWASP-CM-003)''<br /> ''4.3.4 Application Configuration Management Testing (OWASP-CM-004)''<br /> ''4.3.5 Testing for File Extensions Handling (OWASP-CM-005)''<br /> ''4.3.6 Old, Backup and Unreferenced Files (OWASP-CM-006)''<br /> ''4.3.7 Infrastructure and Application Admin Interfaces (OWASP-CM-007)''<br /> ''4.3.8 Testing for HTTP Methods and XST (OWASP-CM-008)''<br /> <br /> <br /> |-<br /> |'''A7 Insufficient Cryptographic Storage'''<br /> ||''Design''<br /> '''Use strong ciphers (AES 128 or better)'''<br /> '''Use strong hashes (SHA 256 or better) with salts for passwords'''<br /> '''Protect keys more than any other asset'''<br /> <br /> ''Render''<br /> Do not send keys or hashes to the browser<br /> <br /> ||''Design''<br /> '''Use strong ciphers (AES 128 or better)'''<br /> '''Use strong hashes (SHA 256 or better) with salts for passwords'''<br /> '''Protect keys more than any other asset'''<br /> <br /> ''Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen. ''<br /> <br /> ''Tip: It is best to encrypt data on the application server, rather than the database server.''<br /> <br /> ||''Design''<br /> <br /> ''Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being &quot;encrypted&quot; on disk. ''<br /> <br /> ||<br /> <br /> <br /> |-<br /> |'''A8 Failure to Restrict URL access'''<br /> ||''Design''<br /> '''Ensure all non-web data is outside the web root (logs, configuration, etc)'''<br /> '''Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar'''<br /> '''Ensure every page requires a role, even if it is &quot;guest&quot;'''<br /> '' ''<br /> ''Pre-render''<br /> '''Validate user is authenticated'''<br /> '''Validate role is sufficient to view secured URL'''<br /> <br /> ''Render''<br /> '''Send CSRF token '''<br /> ||'''Validate user is authenticated'''<br /> '''Validate role is sufficient to perform secured action'''<br /> '''Validate CSRF token'''<br /> <br /> ''Tip: It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming. ''<br /> <br /> ''Tip: Assume attackers '''will''' learn where &quot;hidden&quot; directories and &quot;random&quot; filenames are, so do not store these files in the web root, even if they are not directly linked.''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)''<br /> ''4.6.1 Testing for Path Traversal (OWASP-AZ-001)''<br /> ''4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)''<br /> <br /> |-<br /> |'''A9 Insufficient Transport Layer Protection'''<br /> ||Use TLS 1.2 or later for all web communications <br /> Buy extended validation (EV) certificates for public web servers<br /> <br /> ''Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.''<br /> ||Mandate strong encrypted communications between web and database servers and any other servers or administrative users<br /> ||Mandate strong encrypted communications with application servers and any other servers or administrative users<br /> <br /> ||''4.3.1 SSL/TLS Testing (OWASP-CM-001)''<br /> ''4.4.1 Credentials transport over an encrypted channel (OWASP-AT-001)''<br /> <br /> |-<br /> |'''A10 Unvalidated Redirects and Forwards'''<br /> ||'''Design the app without URL redirection parameters'''<br /> <br /> ''or''<br /> <br /> ''Render''<br /> Use random indirect object references for redirection parameters<br /> <br /> ||'''Design the app without URL redirection parameters'''<br /> <br /> ''or''<br /> <br /> Obtain direct redirection parameter from random indirect reference access map<br /> (LR) Positive validation of redirection parameter <br /> (NR) Java – Do not forward() requests as this prevents SSO access control mechanisms <br /> <br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||<br /> <br /> |-<br /> |}<br /> <br /> = Authors and Primary Editors =<br /> <br /> Andrew van der Stock vanderaj[at]owasp.org<br /> <br /> Ismael Rocha Gonçalves ismaelrg[at]gmail.com<br /> <br /> = Other Cheatsheets =<br /> {{Cheatsheet_Navigation}}<br /> <br /> [[Category:Cheatsheets]]</div>

Jorge Correa https://wiki.owasp.org/index.php?title=OWASP_Top_Ten_Cheat_Sheet&diff=137271 2012-10-08T20:29:56Z

<p>Jorge Correa: </p> <hr /> <div>= Introduction =<br /> <br /> The following is a developer-centric defensive cheat sheet for the [[OWASP Top Ten Project]]. It also presents a quick reference based on [[OWASP Testing Project]] to help how to identify the risks.<br /> <br /> = OWASP Top Ten Cheat Sheet =<br /> <br /> {| border=1<br /> | <br /> ||'''Presentation'''<br /> ||'''Controller'''<br /> ||'''Model'''<br /> ||'''Testing (OWASP Testing Guide V3)'''<br /> <br /> |-<br /> |'''A1 Injection'''<br /> ||<br /> <br /> ''Render:''<br /> Set a correct content type<br /> Set safe character set (UTF-8)<br /> Set correct locale<br /> <br /> ''On Submit:''<br /> Enforce input field type and lengths <br /> Validate fields and provide feedback<br /> Ensure option selects and radio contain only sent values<br /> ||'''Canonicalize using correct character set'''<br /> '''Positive input validation using correct character set'''<br /> <br /> (NR) Negative input validation.<br /> (LR) Sanitize input.<br /> <br /> ''Tip: updating a negative list (such as looking for &quot;script&quot;, &quot;sCrIpT&quot;, &quot;ßCrîpt&quot;, etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of &quot;bad&quot; words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. ''<br /> ||'''[https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet Parameterized queries]'''<br /> <br /> Object relational model (Hibernate).<br /> Active Record design pattern.<br /> Stored procedures.<br /> Escape mechanisms such as ESAPI's Encoder, EncodeForLDAP() or Encoder.EncodeforOS()<br /> <br /> ''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization ''<br /> <br /> ||''4.8.5 SQL Injection (OWASP-DV-005)''<br /> ''4.8.6 LDAP Injection (OWASP-DV-006)''<br /> ''4.8.7 ORM Injection (OWASP-DV-007)''<br /> ''4.8.8 XML Injection (OWASP-DV-008)''<br /> ''4.8.9 SSI Injection (OWASP-DV-009)''<br /> ''4.8.10 XPath Injection (OWASP-DV-010)''<br /> ''4.8.11 IMAP/SMTP Injection (OWASP-DV-011)''<br /> ''4.8.12 Code Injection (OWASP-DV-012)''<br /> ''4.8.13 OS Commanding (OWASP-DV-013)''<br /> ''4.8.14 Buffer overflow (OWASP-DV-014)''<br /> <br /> <br /> |-<br /> |'''A2 XSS'''<br /> ||<br /> <br /> ''Render''<br /> '''Set correct content type'''<br /> '''Set safe character set (UTF-8) '''<br /> '''Set correct locale'''<br /> '''Output encode all user data as per output context'''<br /> '''Set input constraints '''<br /> <br /> ''On Submit''<br /> Enforce input field type and lengths<br /> Validate fields and provide feedback<br /> Ensure option selects and radio contain only sent values<br /> ||'''Canonicalize using correct character set'''<br /> '''Positive input validation using correct character set'''<br /> <br /> (NR) Negative input validation <br /> (LR) Sanitize input <br /> <br /> ''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.''<br /> ||''Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.''<br /> <br /> ''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data''<br /> <br /> ||''4.8.1 Testing for Reflected Cross Site Scripting (OWASP-DV-001)''<br /> ''4.8.2 Testing for Stored Cross Site Scripting (OWASP-DV-002)''<br /> ''4.8.3 Testing for DOM based Cross Site Scripting (OWASP-DV-003)''<br /> ''4.8.4 Testing for Cross Site Flashing (OWASP-DV004)''<br /> <br /> <br /> |-<br /> |'''A3 Weak authentication and session management'''<br /> ||''Render''<br /> '''Validate user is authenticated'''<br /> '''Validate role is sufficient for this view'''<br /> '''Set &quot;secure&quot; and &quot;HttpOnly&quot; flags for session cookies'''<br /> Send CSRF token with forms<br /> <br /> ||''Design''<br /> '''Only use inbuilt session management'''<br /> '''Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies'''<br /> <br /> '''Validate user is authenticated'''<br /> '''Validate role is sufficient to perform this action'''<br /> Validate CSRF token<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ''Tip: Consider the use of a &quot;governor&quot; to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.''<br /> <br /> ||''4.4.2 Testing for user enumeration (OWASP-AT-002)''<br /> ''4.4.3 Testing for Guessable (Dictionary) User Account (OWASP-AT-003)''<br /> ''4.4.4 Brute Force Testing (OWASP-AT-004)''<br /> ''4.4.6 Testing for vulnerable remember password and pwd reset (OWASP-AT-006)''<br /> ''4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)''<br /> ''4.4.7 Testing for Logout and Browser Cache Management (OWASP-AT-007)''<br /> ''4.4.8 Testing for CAPTCHA (OWASP-AT-008)''<br /> ''4.4.9 Testing Multiple Factors Authentication (OWASP-AT-009)''<br /> ''4.4.10 Testing for Race Conditions (OWASP-AT-010)''<br /> ''4.5.1 Testing for Session Management Schema (OWASP-SM-001)''<br /> ''4.5.2 Testing for Cookies attributes (OWASP-SM-002)''<br /> ''4.5.3 Testing for Session Fixation (OWASP-SM_003)''<br /> ''4.5.4 Testing for Exposed Session Variables (OWASP-SM-004)''<br /> ''4.5.5 Testing for CSRF (OWASP-SM-005)''<br /> ''4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)''<br /> ''4.6.3 Testing for Privilege Escalation (OWASP-AZ-003)''<br /> <br /> <br /> |-<br /> |'''A4 Insecure Direct Object Reference'''<br /> ||'''If data is from internal trusted sources, no data is sent'''<br /> <br /> ''Or''<br /> <br /> ''Render''<br /> '''Send indirect random access reference map value'''<br /> ||'''Obtain data from internal, trusted sources'''<br /> <br /> ''Or ''<br /> <br /> '''Obtain direct value from random access reference access map'''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.6.1 Testing for Path Traversal (OWASP-AZ-001)''<br /> <br /> |-<br /> |'''A5 Cross Site Request Forgery'''<br /> ||''Pre-render''<br /> Validate user is authenticated<br /> Validate role is sufficient for this view<br /> <br /> ''Render''<br /> '''Send CSRF token '''<br /> Set &quot;secure&quot; and &quot;HttpOnly&quot; flags for session cookies<br /> ||'''Validate CSRF token'''<br /> Validate role is sufficient to perform this action<br /> Validate role is sufficient <br /> <br /> ''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.5.5 Testing for CSRF (OWASP-SM-005)''<br /> <br /> |-<br /> |'''A6 Security Misconfiguration'''<br /> ||Ensure web servers and application servers are hardened<br /> <br /> PHP – Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension <br /> ||Ensure web servers and application servers are hardened <br /> <br /> XML – Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer. <br /> ||Ensure database servers are hardened <br /> <br /> ||''4.2.6 Analysis of Error Codes (OWASP-IG-006)''<br /> ''4.3.2 DB Listener Testing (OWASP-CM-002)''<br /> ''4.3.3 Infrastructure Configuration Management Testing (OWASP-CM-003)''<br /> ''4.3.4 Application Configuration Management Testing (OWASP-CM-004)''<br /> ''4.3.5 Testing for File Extensions Handling (OWASP-CM-005)''<br /> ''4.3.6 Old, Backup and Unreferenced Files (OWASP-CM-006)''<br /> ''4.3.7 Infrastructure and Application Admin Interfaces (OWASP-CM-007)''<br /> ''4.3.8 Testing for HTTP Methods and XST (OWASP-CM-008)''<br /> <br /> <br /> |-<br /> |'''A7 Insufficient Cryptographic Storage'''<br /> ||''Design''<br /> '''Use strong ciphers (AES 128 or better)'''<br /> '''Use strong hashes (SHA 256 or better) with salts for passwords'''<br /> '''Protect keys more than any other asset'''<br /> <br /> ''Render''<br /> Do not send keys or hashes to the browser<br /> <br /> ||''Design''<br /> '''Use strong ciphers (AES 128 or better)'''<br /> '''Use strong hashes (SHA 256 or better) with salts for passwords'''<br /> '''Protect keys more than any other asset'''<br /> <br /> ''Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen. ''<br /> <br /> ''Tip: It is best to encrypt data on the application server, rather than the database server.''<br /> <br /> ||''Design''<br /> <br /> ''Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being &quot;encrypted&quot; on disk. ''<br /> <br /> ||<br /> <br /> <br /> |-<br /> |'''A8 Failure to Restrict URL access'''<br /> ||''Design''<br /> '''Ensure all non-web data is outside the web root (logs, configuration, etc)'''<br /> '''Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar'''<br /> '''Ensure every page requires a role, even if it is &quot;guest&quot;'''<br /> '' ''<br /> ''Pre-render''<br /> '''Validate user is authenticated'''<br /> '''Validate role is sufficient to view secured URL'''<br /> <br /> ''Render''<br /> '''Send CSRF token '''<br /> ||'''Validate user is authenticated'''<br /> '''Validate role is sufficient to perform secured action'''<br /> '''Validate CSRF token'''<br /> <br /> ''Tip: It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming. ''<br /> <br /> ''Tip: Assume attackers '''will''' learn where &quot;hidden&quot; directories and &quot;random&quot; filenames are, so do not store these files in the web root, even if they are not directly linked.''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)''<br /> ''4.6.1 Testing for Path Traversal (OWASP-AZ-001)''<br /> ''4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)''<br /> <br /> |-<br /> |'''A9 Insufficient Transport Layer Protection'''<br /> ||Use TLS 1.2 or later for all web communications <br /> Buy extended validation (EV) certificates for public web servers<br /> <br /> ''Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.''<br /> ||Mandate strong encrypted communications between web and database servers and any other servers or administrative users<br /> ||Mandate strong encrypted communications with application servers and any other servers or administrative users<br /> <br /> ||''4.3.1 SSL/TLS Testing (OWASP-CM-001)''<br /> ''4.4.1 Credentials transport over an encrypted channel (OWASP-AT-001)''<br /> <br /> |-<br /> |'''A10 Unvalidated Redirects and Forwards'''<br /> ||'''Design the app without URL redirection parameters'''<br /> <br /> ''or''<br /> <br /> ''Render''<br /> Use random indirect object references for redirection parameters<br /> <br /> ||'''Design the app without URL redirection parameters'''<br /> <br /> ''or''<br /> <br /> Obtain direct redirection parameter from random indirect reference access map<br /> (LR) Positive validation of redirection parameter <br /> (NR) Java – Do not forward() requests as this prevents SSO access control mechanisms <br /> <br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||<br /> <br /> |-<br /> |}<br /> <br /> = Authors and Primary Editors =<br /> <br /> Andrew van der Stock vanderaj[at]owasp.org<br /> <br /> Ismael Rocha Gonçalves ismaelrg[at]gmail.com<br /> <br /> = Other Cheatsheets =<br /> {{Cheatsheet_Navigation}}<br /> <br /> [[Category:Cheatsheets]]</div>

Jorge Correa https://wiki.owasp.org/index.php?title=OWASP_Top_Ten_Cheat_Sheet&diff=137270 2012-10-08T20:29:20Z

<p>Jorge Correa: </p> <hr /> <div>= Introduction =<br /> <br /> The following is a developer-centric defensive cheat sheet for the [[OWASP Top Ten Project]]. It also presents a quick reference based on [[OWASP Testing Project]] to help how to identify the risks.<br /> <br /> = OWASP Top Ten Cheat Sheet =<br /> <br /> {| border=1<br /> | <br /> ||'''Presentation'''<br /> ||'''Controller'''<br /> ||'''Model'''<br /> ||'''Testing (OWASP Testing Guide V3)'''<br /> <br /> |-<br /> |'''A1 Injection'''<br /> ||<br /> <br /> ''Render:''<br /> Set a correct content type<br /> Set safe character set (UTF-8)<br /> Set correct locale<br /> <br /> ''On Submit:''<br /> Enforce input field type and lengths <br /> Validate fields and provide feedback<br /> Ensure option selects and radio contain only sent values<br /> ||'''Canonicalize using correct character set'''<br /> '''Positive input validation using correct character set'''<br /> <br /> (NR) Negative input validation.<br /> (LR) Sanitize input.<br /> <br /> ''Tip: updating a negative list (such as looking for &quot;script&quot;, &quot;sCrIpT&quot;, &quot;ßCrîpt&quot;, etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of &quot;bad&quot; words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. ''<br /> ||'''[https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet Parameterized queries]'''<br /> ''Object relational model (Hibernate).''<br /> ''Active Record design pattern.''<br /> ''Stored procedures.''<br /> Escape mechanisms such as ESAPI's Encoder, EncodeForLDAP() or Encoder.EncodeforOS()<br /> <br /> ''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization ''<br /> <br /> ||''4.8.5 SQL Injection (OWASP-DV-005)''<br /> ''4.8.6 LDAP Injection (OWASP-DV-006)''<br /> ''4.8.7 ORM Injection (OWASP-DV-007)''<br /> ''4.8.8 XML Injection (OWASP-DV-008)''<br /> ''4.8.9 SSI Injection (OWASP-DV-009)''<br /> ''4.8.10 XPath Injection (OWASP-DV-010)''<br /> ''4.8.11 IMAP/SMTP Injection (OWASP-DV-011)''<br /> ''4.8.12 Code Injection (OWASP-DV-012)''<br /> ''4.8.13 OS Commanding (OWASP-DV-013)''<br /> ''4.8.14 Buffer overflow (OWASP-DV-014)''<br /> <br /> <br /> |-<br /> |'''A2 XSS'''<br /> ||<br /> <br /> ''Render''<br /> '''Set correct content type'''<br /> '''Set safe character set (UTF-8) '''<br /> '''Set correct locale'''<br /> '''Output encode all user data as per output context'''<br /> '''Set input constraints '''<br /> <br /> ''On Submit''<br /> Enforce input field type and lengths<br /> Validate fields and provide feedback<br /> Ensure option selects and radio contain only sent values<br /> ||'''Canonicalize using correct character set'''<br /> '''Positive input validation using correct character set'''<br /> <br /> (NR) Negative input validation <br /> (LR) Sanitize input <br /> <br /> ''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.''<br /> ||''Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.''<br /> <br /> ''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data''<br /> <br /> ||''4.8.1 Testing for Reflected Cross Site Scripting (OWASP-DV-001)''<br /> ''4.8.2 Testing for Stored Cross Site Scripting (OWASP-DV-002)''<br /> ''4.8.3 Testing for DOM based Cross Site Scripting (OWASP-DV-003)''<br /> ''4.8.4 Testing for Cross Site Flashing (OWASP-DV004)''<br /> <br /> <br /> |-<br /> |'''A3 Weak authentication and session management'''<br /> ||''Render''<br /> '''Validate user is authenticated'''<br /> '''Validate role is sufficient for this view'''<br /> '''Set &quot;secure&quot; and &quot;HttpOnly&quot; flags for session cookies'''<br /> Send CSRF token with forms<br /> <br /> ||''Design''<br /> '''Only use inbuilt session management'''<br /> '''Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies'''<br /> <br /> '''Validate user is authenticated'''<br /> '''Validate role is sufficient to perform this action'''<br /> Validate CSRF token<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ''Tip: Consider the use of a &quot;governor&quot; to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.''<br /> <br /> ||''4.4.2 Testing for user enumeration (OWASP-AT-002)''<br /> ''4.4.3 Testing for Guessable (Dictionary) User Account (OWASP-AT-003)''<br /> ''4.4.4 Brute Force Testing (OWASP-AT-004)''<br /> ''4.4.6 Testing for vulnerable remember password and pwd reset (OWASP-AT-006)''<br /> ''4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)''<br /> ''4.4.7 Testing for Logout and Browser Cache Management (OWASP-AT-007)''<br /> ''4.4.8 Testing for CAPTCHA (OWASP-AT-008)''<br /> ''4.4.9 Testing Multiple Factors Authentication (OWASP-AT-009)''<br /> ''4.4.10 Testing for Race Conditions (OWASP-AT-010)''<br /> ''4.5.1 Testing for Session Management Schema (OWASP-SM-001)''<br /> ''4.5.2 Testing for Cookies attributes (OWASP-SM-002)''<br /> ''4.5.3 Testing for Session Fixation (OWASP-SM_003)''<br /> ''4.5.4 Testing for Exposed Session Variables (OWASP-SM-004)''<br /> ''4.5.5 Testing for CSRF (OWASP-SM-005)''<br /> ''4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)''<br /> ''4.6.3 Testing for Privilege Escalation (OWASP-AZ-003)''<br /> <br /> <br /> |-<br /> |'''A4 Insecure Direct Object Reference'''<br /> ||'''If data is from internal trusted sources, no data is sent'''<br /> <br /> ''Or''<br /> <br /> ''Render''<br /> '''Send indirect random access reference map value'''<br /> ||'''Obtain data from internal, trusted sources'''<br /> <br /> ''Or ''<br /> <br /> '''Obtain direct value from random access reference access map'''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.6.1 Testing for Path Traversal (OWASP-AZ-001)''<br /> <br /> |-<br /> |'''A5 Cross Site Request Forgery'''<br /> ||''Pre-render''<br /> Validate user is authenticated<br /> Validate role is sufficient for this view<br /> <br /> ''Render''<br /> '''Send CSRF token '''<br /> Set &quot;secure&quot; and &quot;HttpOnly&quot; flags for session cookies<br /> ||'''Validate CSRF token'''<br /> Validate role is sufficient to perform this action<br /> Validate role is sufficient <br /> <br /> ''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.5.5 Testing for CSRF (OWASP-SM-005)''<br /> <br /> |-<br /> |'''A6 Security Misconfiguration'''<br /> ||Ensure web servers and application servers are hardened<br /> <br /> PHP – Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension <br /> ||Ensure web servers and application servers are hardened <br /> <br /> XML – Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer. <br /> ||Ensure database servers are hardened <br /> <br /> ||''4.2.6 Analysis of Error Codes (OWASP-IG-006)''<br /> ''4.3.2 DB Listener Testing (OWASP-CM-002)''<br /> ''4.3.3 Infrastructure Configuration Management Testing (OWASP-CM-003)''<br /> ''4.3.4 Application Configuration Management Testing (OWASP-CM-004)''<br /> ''4.3.5 Testing for File Extensions Handling (OWASP-CM-005)''<br /> ''4.3.6 Old, Backup and Unreferenced Files (OWASP-CM-006)''<br /> ''4.3.7 Infrastructure and Application Admin Interfaces (OWASP-CM-007)''<br /> ''4.3.8 Testing for HTTP Methods and XST (OWASP-CM-008)''<br /> <br /> <br /> |-<br /> |'''A7 Insufficient Cryptographic Storage'''<br /> ||''Design''<br /> '''Use strong ciphers (AES 128 or better)'''<br /> '''Use strong hashes (SHA 256 or better) with salts for passwords'''<br /> '''Protect keys more than any other asset'''<br /> <br /> ''Render''<br /> Do not send keys or hashes to the browser<br /> <br /> ||''Design''<br /> '''Use strong ciphers (AES 128 or better)'''<br /> '''Use strong hashes (SHA 256 or better) with salts for passwords'''<br /> '''Protect keys more than any other asset'''<br /> <br /> ''Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen. ''<br /> <br /> ''Tip: It is best to encrypt data on the application server, rather than the database server.''<br /> <br /> ||''Design''<br /> <br /> ''Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being &quot;encrypted&quot; on disk. ''<br /> <br /> ||<br /> <br /> <br /> |-<br /> |'''A8 Failure to Restrict URL access'''<br /> ||''Design''<br /> '''Ensure all non-web data is outside the web root (logs, configuration, etc)'''<br /> '''Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar'''<br /> '''Ensure every page requires a role, even if it is &quot;guest&quot;'''<br /> '' ''<br /> ''Pre-render''<br /> '''Validate user is authenticated'''<br /> '''Validate role is sufficient to view secured URL'''<br /> <br /> ''Render''<br /> '''Send CSRF token '''<br /> ||'''Validate user is authenticated'''<br /> '''Validate role is sufficient to perform secured action'''<br /> '''Validate CSRF token'''<br /> <br /> ''Tip: It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming. ''<br /> <br /> ''Tip: Assume attackers '''will''' learn where &quot;hidden&quot; directories and &quot;random&quot; filenames are, so do not store these files in the web root, even if they are not directly linked.''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)''<br /> ''4.6.1 Testing for Path Traversal (OWASP-AZ-001)''<br /> ''4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)''<br /> <br /> |-<br /> |'''A9 Insufficient Transport Layer Protection'''<br /> ||Use TLS 1.2 or later for all web communications <br /> Buy extended validation (EV) certificates for public web servers<br /> <br /> ''Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.''<br /> ||Mandate strong encrypted communications between web and database servers and any other servers or administrative users<br /> ||Mandate strong encrypted communications with application servers and any other servers or administrative users<br /> <br /> ||''4.3.1 SSL/TLS Testing (OWASP-CM-001)''<br /> ''4.4.1 Credentials transport over an encrypted channel (OWASP-AT-001)''<br /> <br /> |-<br /> |'''A10 Unvalidated Redirects and Forwards'''<br /> ||'''Design the app without URL redirection parameters'''<br /> <br /> ''or''<br /> <br /> ''Render''<br /> Use random indirect object references for redirection parameters<br /> <br /> ||'''Design the app without URL redirection parameters'''<br /> <br /> ''or''<br /> <br /> Obtain direct redirection parameter from random indirect reference access map<br /> (LR) Positive validation of redirection parameter <br /> (NR) Java – Do not forward() requests as this prevents SSO access control mechanisms <br /> <br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||<br /> <br /> |-<br /> |}<br /> <br /> = Authors and Primary Editors =<br /> <br /> Andrew van der Stock vanderaj[at]owasp.org<br /> <br /> Ismael Rocha Gonçalves ismaelrg[at]gmail.com<br /> <br /> = Other Cheatsheets =<br /> {{Cheatsheet_Navigation}}<br /> <br /> [[Category:Cheatsheets]]</div>

Jorge Correa https://wiki.owasp.org/index.php?title=OWASP_Top_Ten_Cheat_Sheet&diff=137269 2012-10-08T20:28:12Z

<p>Jorge Correa: </p> <hr /> <div>= Introduction =<br /> <br /> The following is a developer-centric defensive cheat sheet for the [[OWASP Top Ten Project]]. It also presents a quick reference based on [[OWASP Testing Project]] to help how to identify the risks.<br /> <br /> = OWASP Top Ten Cheat Sheet =<br /> <br /> {| border=1<br /> | <br /> ||'''Presentation'''<br /> ||'''Controller'''<br /> ||'''Model'''<br /> ||'''Testing (OWASP Testing Guide V3)'''<br /> <br /> |-<br /> |'''A1 Injection'''<br /> ||<br /> <br /> ''Render:''<br /> Set a correct content type<br /> Set safe character set (UTF-8)<br /> Set correct locale<br /> <br /> ''On Submit:''<br /> Enforce input field type and lengths <br /> Validate fields and provide feedback<br /> Ensure option selects and radio contain only sent values<br /> ||'''Canonicalize using correct character set'''<br /> '''Positive input validation using correct character set'''<br /> <br /> (NR) Negative input validation <br /> (LR) Sanitize input <br /> <br /> ''Tip: updating a negative list (such as looking for &quot;script&quot;, &quot;sCrIpT&quot;, &quot;ßCrîpt&quot;, etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of &quot;bad&quot; words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. ''<br /> ||'''[https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet Parameterized queries]'''<br /> Object relational model (Hibernate).<br /> <br /> Active Record design pattern.<br /> <br /> Stored procedures.<br /> <br /> Escape mechanisms such as ESAPI's Encoder, EncodeForLDAP() or Encoder.EncodeforOS()<br /> <br /> ''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization ''<br /> <br /> ||''4.8.5 SQL Injection (OWASP-DV-005)''<br /> ''4.8.6 LDAP Injection (OWASP-DV-006)''<br /> ''4.8.7 ORM Injection (OWASP-DV-007)''<br /> ''4.8.8 XML Injection (OWASP-DV-008)''<br /> ''4.8.9 SSI Injection (OWASP-DV-009)''<br /> ''4.8.10 XPath Injection (OWASP-DV-010)''<br /> ''4.8.11 IMAP/SMTP Injection (OWASP-DV-011)''<br /> ''4.8.12 Code Injection (OWASP-DV-012)''<br /> ''4.8.13 OS Commanding (OWASP-DV-013)''<br /> ''4.8.14 Buffer overflow (OWASP-DV-014)''<br /> <br /> <br /> |-<br /> |'''A2 XSS'''<br /> ||<br /> <br /> ''Render''<br /> '''Set correct content type'''<br /> '''Set safe character set (UTF-8) '''<br /> '''Set correct locale'''<br /> '''Output encode all user data as per output context'''<br /> '''Set input constraints '''<br /> <br /> ''On Submit''<br /> Enforce input field type and lengths<br /> Validate fields and provide feedback<br /> Ensure option selects and radio contain only sent values<br /> ||'''Canonicalize using correct character set'''<br /> '''Positive input validation using correct character set'''<br /> <br /> (NR) Negative input validation <br /> (LR) Sanitize input <br /> <br /> ''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.''<br /> ||''Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.''<br /> <br /> ''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data''<br /> <br /> ||''4.8.1 Testing for Reflected Cross Site Scripting (OWASP-DV-001)''<br /> ''4.8.2 Testing for Stored Cross Site Scripting (OWASP-DV-002)''<br /> ''4.8.3 Testing for DOM based Cross Site Scripting (OWASP-DV-003)''<br /> ''4.8.4 Testing for Cross Site Flashing (OWASP-DV004)''<br /> <br /> <br /> |-<br /> |'''A3 Weak authentication and session management'''<br /> ||''Render''<br /> '''Validate user is authenticated'''<br /> '''Validate role is sufficient for this view'''<br /> '''Set &quot;secure&quot; and &quot;HttpOnly&quot; flags for session cookies'''<br /> Send CSRF token with forms<br /> <br /> ||''Design''<br /> '''Only use inbuilt session management'''<br /> '''Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies'''<br /> <br /> '''Validate user is authenticated'''<br /> '''Validate role is sufficient to perform this action'''<br /> Validate CSRF token<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ''Tip: Consider the use of a &quot;governor&quot; to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.''<br /> <br /> ||''4.4.2 Testing for user enumeration (OWASP-AT-002)''<br /> ''4.4.3 Testing for Guessable (Dictionary) User Account (OWASP-AT-003)''<br /> ''4.4.4 Brute Force Testing (OWASP-AT-004)''<br /> ''4.4.6 Testing for vulnerable remember password and pwd reset (OWASP-AT-006)''<br /> ''4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)''<br /> ''4.4.7 Testing for Logout and Browser Cache Management (OWASP-AT-007)''<br /> ''4.4.8 Testing for CAPTCHA (OWASP-AT-008)''<br /> ''4.4.9 Testing Multiple Factors Authentication (OWASP-AT-009)''<br /> ''4.4.10 Testing for Race Conditions (OWASP-AT-010)''<br /> ''4.5.1 Testing for Session Management Schema (OWASP-SM-001)''<br /> ''4.5.2 Testing for Cookies attributes (OWASP-SM-002)''<br /> ''4.5.3 Testing for Session Fixation (OWASP-SM_003)''<br /> ''4.5.4 Testing for Exposed Session Variables (OWASP-SM-004)''<br /> ''4.5.5 Testing for CSRF (OWASP-SM-005)''<br /> ''4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)''<br /> ''4.6.3 Testing for Privilege Escalation (OWASP-AZ-003)''<br /> <br /> <br /> |-<br /> |'''A4 Insecure Direct Object Reference'''<br /> ||'''If data is from internal trusted sources, no data is sent'''<br /> <br /> ''Or''<br /> <br /> ''Render''<br /> '''Send indirect random access reference map value'''<br /> ||'''Obtain data from internal, trusted sources'''<br /> <br /> ''Or ''<br /> <br /> '''Obtain direct value from random access reference access map'''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.6.1 Testing for Path Traversal (OWASP-AZ-001)''<br /> <br /> |-<br /> |'''A5 Cross Site Request Forgery'''<br /> ||''Pre-render''<br /> Validate user is authenticated<br /> Validate role is sufficient for this view<br /> <br /> ''Render''<br /> '''Send CSRF token '''<br /> Set &quot;secure&quot; and &quot;HttpOnly&quot; flags for session cookies<br /> ||'''Validate CSRF token'''<br /> Validate role is sufficient to perform this action<br /> Validate role is sufficient <br /> <br /> ''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.5.5 Testing for CSRF (OWASP-SM-005)''<br /> <br /> |-<br /> |'''A6 Security Misconfiguration'''<br /> ||Ensure web servers and application servers are hardened<br /> <br /> PHP – Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension <br /> ||Ensure web servers and application servers are hardened <br /> <br /> XML – Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer. <br /> ||Ensure database servers are hardened <br /> <br /> ||''4.2.6 Analysis of Error Codes (OWASP-IG-006)''<br /> ''4.3.2 DB Listener Testing (OWASP-CM-002)''<br /> ''4.3.3 Infrastructure Configuration Management Testing (OWASP-CM-003)''<br /> ''4.3.4 Application Configuration Management Testing (OWASP-CM-004)''<br /> ''4.3.5 Testing for File Extensions Handling (OWASP-CM-005)''<br /> ''4.3.6 Old, Backup and Unreferenced Files (OWASP-CM-006)''<br /> ''4.3.7 Infrastructure and Application Admin Interfaces (OWASP-CM-007)''<br /> ''4.3.8 Testing for HTTP Methods and XST (OWASP-CM-008)''<br /> <br /> <br /> |-<br /> |'''A7 Insufficient Cryptographic Storage'''<br /> ||''Design''<br /> '''Use strong ciphers (AES 128 or better)'''<br /> '''Use strong hashes (SHA 256 or better) with salts for passwords'''<br /> '''Protect keys more than any other asset'''<br /> <br /> ''Render''<br /> Do not send keys or hashes to the browser<br /> <br /> ||''Design''<br /> '''Use strong ciphers (AES 128 or better)'''<br /> '''Use strong hashes (SHA 256 or better) with salts for passwords'''<br /> '''Protect keys more than any other asset'''<br /> <br /> ''Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen. ''<br /> <br /> ''Tip: It is best to encrypt data on the application server, rather than the database server.''<br /> <br /> ||''Design''<br /> <br /> ''Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being &quot;encrypted&quot; on disk. ''<br /> <br /> ||<br /> <br /> <br /> |-<br /> |'''A8 Failure to Restrict URL access'''<br /> ||''Design''<br /> '''Ensure all non-web data is outside the web root (logs, configuration, etc)'''<br /> '''Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar'''<br /> '''Ensure every page requires a role, even if it is &quot;guest&quot;'''<br /> '' ''<br /> ''Pre-render''<br /> '''Validate user is authenticated'''<br /> '''Validate role is sufficient to view secured URL'''<br /> <br /> ''Render''<br /> '''Send CSRF token '''<br /> ||'''Validate user is authenticated'''<br /> '''Validate role is sufficient to perform secured action'''<br /> '''Validate CSRF token'''<br /> <br /> ''Tip: It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming. ''<br /> <br /> ''Tip: Assume attackers '''will''' learn where &quot;hidden&quot; directories and &quot;random&quot; filenames are, so do not store these files in the web root, even if they are not directly linked.''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)''<br /> ''4.6.1 Testing for Path Traversal (OWASP-AZ-001)''<br /> ''4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)''<br /> <br /> |-<br /> |'''A9 Insufficient Transport Layer Protection'''<br /> ||Use TLS 1.2 or later for all web communications <br /> Buy extended validation (EV) certificates for public web servers<br /> <br /> ''Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.''<br /> ||Mandate strong encrypted communications between web and database servers and any other servers or administrative users<br /> ||Mandate strong encrypted communications with application servers and any other servers or administrative users<br /> <br /> ||''4.3.1 SSL/TLS Testing (OWASP-CM-001)''<br /> ''4.4.1 Credentials transport over an encrypted channel (OWASP-AT-001)''<br /> <br /> |-<br /> |'''A10 Unvalidated Redirects and Forwards'''<br /> ||'''Design the app without URL redirection parameters'''<br /> <br /> ''or''<br /> <br /> ''Render''<br /> Use random indirect object references for redirection parameters<br /> <br /> ||'''Design the app without URL redirection parameters'''<br /> <br /> ''or''<br /> <br /> Obtain direct redirection parameter from random indirect reference access map<br /> (LR) Positive validation of redirection parameter <br /> (NR) Java – Do not forward() requests as this prevents SSO access control mechanisms <br /> <br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||<br /> <br /> |-<br /> |}<br /> <br /> = Authors and Primary Editors =<br /> <br /> Andrew van der Stock vanderaj[at]owasp.org<br /> <br /> Ismael Rocha Gonçalves ismaelrg[at]gmail.com<br /> <br /> = Other Cheatsheets =<br /> {{Cheatsheet_Navigation}}<br /> <br /> [[Category:Cheatsheets]]</div>

Jorge Correa https://wiki.owasp.org/index.php?title=OWASP_Top_Ten_Cheat_Sheet&diff=137268 2012-10-08T20:27:31Z

<p>Jorge Correa: </p> <hr /> <div>= Introduction =<br /> <br /> The following is a developer-centric defensive cheat sheet for the [[OWASP Top Ten Project]]. It also presents a quick reference based on [[OWASP Testing Project]] to help how to identify the risks.<br /> <br /> = OWASP Top Ten Cheat Sheet =<br /> <br /> {| border=1<br /> | <br /> ||'''Presentation'''<br /> ||'''Controller'''<br /> ||'''Model'''<br /> ||'''Testing (OWASP Testing Guide V3)'''<br /> <br /> |-<br /> |'''A1 Injection'''<br /> ||<br /> <br /> ''Render:''<br /> Set a correct content type<br /> Set safe character set (UTF-8)<br /> Set correct locale<br /> <br /> ''On Submit:''<br /> Enforce input field type and lengths <br /> Validate fields and provide feedback<br /> Ensure option selects and radio contain only sent values<br /> ||'''Canonicalize using correct character set'''<br /> '''Positive input validation using correct character set'''<br /> <br /> (NR) Negative input validation <br /> (LR) Sanitize input <br /> <br /> ''Tip: updating a negative list (such as looking for &quot;script&quot;, &quot;sCrIpT&quot;, &quot;ßCrîpt&quot;, etc) will require expensive and constant deployments and will '''always '''fail as attackers work out your list of &quot;bad&quot; words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. ''<br /> ||'''[https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet Parameterized queries]'''<br /> Object relational model (Hibernate).<br /> Active Record design pattern.<br /> Stored procedures.<br /> <br /> Escape mechanisms such as ESAPI's Encoder, EncodeForLDAP() or Encoder.EncodeforOS()<br /> <br /> ''Tip: '''All '''SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization ''<br /> <br /> ||''4.8.5 SQL Injection (OWASP-DV-005)''<br /> ''4.8.6 LDAP Injection (OWASP-DV-006)''<br /> ''4.8.7 ORM Injection (OWASP-DV-007)''<br /> ''4.8.8 XML Injection (OWASP-DV-008)''<br /> ''4.8.9 SSI Injection (OWASP-DV-009)''<br /> ''4.8.10 XPath Injection (OWASP-DV-010)''<br /> ''4.8.11 IMAP/SMTP Injection (OWASP-DV-011)''<br /> ''4.8.12 Code Injection (OWASP-DV-012)''<br /> ''4.8.13 OS Commanding (OWASP-DV-013)''<br /> ''4.8.14 Buffer overflow (OWASP-DV-014)''<br /> <br /> <br /> |-<br /> |'''A2 XSS'''<br /> ||<br /> <br /> ''Render''<br /> '''Set correct content type'''<br /> '''Set safe character set (UTF-8) '''<br /> '''Set correct locale'''<br /> '''Output encode all user data as per output context'''<br /> '''Set input constraints '''<br /> <br /> ''On Submit''<br /> Enforce input field type and lengths<br /> Validate fields and provide feedback<br /> Ensure option selects and radio contain only sent values<br /> ||'''Canonicalize using correct character set'''<br /> '''Positive input validation using correct character set'''<br /> <br /> (NR) Negative input validation <br /> (LR) Sanitize input <br /> <br /> ''Tip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected.''<br /> ||''Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.''<br /> <br /> ''Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data''<br /> <br /> ||''4.8.1 Testing for Reflected Cross Site Scripting (OWASP-DV-001)''<br /> ''4.8.2 Testing for Stored Cross Site Scripting (OWASP-DV-002)''<br /> ''4.8.3 Testing for DOM based Cross Site Scripting (OWASP-DV-003)''<br /> ''4.8.4 Testing for Cross Site Flashing (OWASP-DV004)''<br /> <br /> <br /> |-<br /> |'''A3 Weak authentication and session management'''<br /> ||''Render''<br /> '''Validate user is authenticated'''<br /> '''Validate role is sufficient for this view'''<br /> '''Set &quot;secure&quot; and &quot;HttpOnly&quot; flags for session cookies'''<br /> Send CSRF token with forms<br /> <br /> ||''Design''<br /> '''Only use inbuilt session management'''<br /> '''Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies'''<br /> <br /> '''Validate user is authenticated'''<br /> '''Validate role is sufficient to perform this action'''<br /> Validate CSRF token<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ''Tip: Consider the use of a &quot;governor&quot; to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked.''<br /> <br /> ||''4.4.2 Testing for user enumeration (OWASP-AT-002)''<br /> ''4.4.3 Testing for Guessable (Dictionary) User Account (OWASP-AT-003)''<br /> ''4.4.4 Brute Force Testing (OWASP-AT-004)''<br /> ''4.4.6 Testing for vulnerable remember password and pwd reset (OWASP-AT-006)''<br /> ''4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)''<br /> ''4.4.7 Testing for Logout and Browser Cache Management (OWASP-AT-007)''<br /> ''4.4.8 Testing for CAPTCHA (OWASP-AT-008)''<br /> ''4.4.9 Testing Multiple Factors Authentication (OWASP-AT-009)''<br /> ''4.4.10 Testing for Race Conditions (OWASP-AT-010)''<br /> ''4.5.1 Testing for Session Management Schema (OWASP-SM-001)''<br /> ''4.5.2 Testing for Cookies attributes (OWASP-SM-002)''<br /> ''4.5.3 Testing for Session Fixation (OWASP-SM_003)''<br /> ''4.5.4 Testing for Exposed Session Variables (OWASP-SM-004)''<br /> ''4.5.5 Testing for CSRF (OWASP-SM-005)''<br /> ''4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)''<br /> ''4.6.3 Testing for Privilege Escalation (OWASP-AZ-003)''<br /> <br /> <br /> |-<br /> |'''A4 Insecure Direct Object Reference'''<br /> ||'''If data is from internal trusted sources, no data is sent'''<br /> <br /> ''Or''<br /> <br /> ''Render''<br /> '''Send indirect random access reference map value'''<br /> ||'''Obtain data from internal, trusted sources'''<br /> <br /> ''Or ''<br /> <br /> '''Obtain direct value from random access reference access map'''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.6.1 Testing for Path Traversal (OWASP-AZ-001)''<br /> <br /> |-<br /> |'''A5 Cross Site Request Forgery'''<br /> ||''Pre-render''<br /> Validate user is authenticated<br /> Validate role is sufficient for this view<br /> <br /> ''Render''<br /> '''Send CSRF token '''<br /> Set &quot;secure&quot; and &quot;HttpOnly&quot; flags for session cookies<br /> ||'''Validate CSRF token'''<br /> Validate role is sufficient to perform this action<br /> Validate role is sufficient <br /> <br /> ''Tip: CSRF is '''always '''possible if there is XSS, so make sure XSS is eliminated within your application.''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.5.5 Testing for CSRF (OWASP-SM-005)''<br /> <br /> |-<br /> |'''A6 Security Misconfiguration'''<br /> ||Ensure web servers and application servers are hardened<br /> <br /> PHP – Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension <br /> ||Ensure web servers and application servers are hardened <br /> <br /> XML – Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer. <br /> ||Ensure database servers are hardened <br /> <br /> ||''4.2.6 Analysis of Error Codes (OWASP-IG-006)''<br /> ''4.3.2 DB Listener Testing (OWASP-CM-002)''<br /> ''4.3.3 Infrastructure Configuration Management Testing (OWASP-CM-003)''<br /> ''4.3.4 Application Configuration Management Testing (OWASP-CM-004)''<br /> ''4.3.5 Testing for File Extensions Handling (OWASP-CM-005)''<br /> ''4.3.6 Old, Backup and Unreferenced Files (OWASP-CM-006)''<br /> ''4.3.7 Infrastructure and Application Admin Interfaces (OWASP-CM-007)''<br /> ''4.3.8 Testing for HTTP Methods and XST (OWASP-CM-008)''<br /> <br /> <br /> |-<br /> |'''A7 Insufficient Cryptographic Storage'''<br /> ||''Design''<br /> '''Use strong ciphers (AES 128 or better)'''<br /> '''Use strong hashes (SHA 256 or better) with salts for passwords'''<br /> '''Protect keys more than any other asset'''<br /> <br /> ''Render''<br /> Do not send keys or hashes to the browser<br /> <br /> ||''Design''<br /> '''Use strong ciphers (AES 128 or better)'''<br /> '''Use strong hashes (SHA 256 or better) with salts for passwords'''<br /> '''Protect keys more than any other asset'''<br /> <br /> ''Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen. ''<br /> <br /> ''Tip: It is best to encrypt data on the application server, rather than the database server.''<br /> <br /> ||''Design''<br /> <br /> ''Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being &quot;encrypted&quot; on disk. ''<br /> <br /> ||<br /> <br /> <br /> |-<br /> |'''A8 Failure to Restrict URL access'''<br /> ||''Design''<br /> '''Ensure all non-web data is outside the web root (logs, configuration, etc)'''<br /> '''Use octet byte streaming instead of providing access to real files such as PDFs or CSVs or similar'''<br /> '''Ensure every page requires a role, even if it is &quot;guest&quot;'''<br /> '' ''<br /> ''Pre-render''<br /> '''Validate user is authenticated'''<br /> '''Validate role is sufficient to view secured URL'''<br /> <br /> ''Render''<br /> '''Send CSRF token '''<br /> ||'''Validate user is authenticated'''<br /> '''Validate role is sufficient to perform secured action'''<br /> '''Validate CSRF token'''<br /> <br /> ''Tip: It's impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming. ''<br /> <br /> ''Tip: Assume attackers '''will''' learn where &quot;hidden&quot; directories and &quot;random&quot; filenames are, so do not store these files in the web root, even if they are not directly linked.''<br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||''4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)''<br /> ''4.6.1 Testing for Path Traversal (OWASP-AZ-001)''<br /> ''4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)''<br /> <br /> |-<br /> |'''A9 Insufficient Transport Layer Protection'''<br /> ||Use TLS 1.2 or later for all web communications <br /> Buy extended validation (EV) certificates for public web servers<br /> <br /> ''Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite.''<br /> ||Mandate strong encrypted communications between web and database servers and any other servers or administrative users<br /> ||Mandate strong encrypted communications with application servers and any other servers or administrative users<br /> <br /> ||''4.3.1 SSL/TLS Testing (OWASP-CM-001)''<br /> ''4.4.1 Credentials transport over an encrypted channel (OWASP-AT-001)''<br /> <br /> |-<br /> |'''A10 Unvalidated Redirects and Forwards'''<br /> ||'''Design the app without URL redirection parameters'''<br /> <br /> ''or''<br /> <br /> ''Render''<br /> Use random indirect object references for redirection parameters<br /> <br /> ||'''Design the app without URL redirection parameters'''<br /> <br /> ''or''<br /> <br /> Obtain direct redirection parameter from random indirect reference access map<br /> (LR) Positive validation of redirection parameter <br /> (NR) Java – Do not forward() requests as this prevents SSO access control mechanisms <br /> <br /> ||Validate role is sufficient to create, read, update, or delete data<br /> <br /> ||<br /> <br /> |-<br /> |}<br /> <br /> = Authors and Primary Editors =<br /> <br /> Andrew van der Stock vanderaj[at]owasp.org<br /> <br /> Ismael Rocha Gonçalves ismaelrg[at]gmail.com<br /> <br /> = Other Cheatsheets =<br /> {{Cheatsheet_Navigation}}<br /> <br /> [[Category:Cheatsheets]]</div>

Jorge Correa https://wiki.owasp.org/index.php?title=Web_Services&diff=114619 2011-07-26T16:18:31Z

<p>Jorge Correa: </p> <hr /> <div>[[Guide Table of Contents|Development Guide Table of Contents]] __TOC__ This section of the Development Guide details the common issues facing Web services developers, and methods to address common issues. Due to the space limitations, it cannot look at all of the surrounding issues in great detail, since each of them deserves a separate book of its own. Instead, an attempt is made to steer the reader to the appropriate usage patterns, and warn about potential roadblocks on the way. <br /> <br /> Web Services have received a lot of press, and with that comes a great deal of confusion over what they really are. Some are heralding Web Services as the biggest technology breakthrough since the web itself; others are more skeptical that they are nothing more than evolved web applications. In either case, the issues of web application security apply to web services just as they do to web applications. <br /> <br /> == What are Web Services? ==<br /> <br /> Suppose you were making an application that you wanted other applications to be able to communicate with. For example, your Java application has stock information updated every 5 minutes and you would like other applications, ones that may not even exist yet, to be able to use the data. <br /> <br /> One way you can do this is to serialize your Java objects and send them over the wire to the application that requests them. The problem with this approach is that a C# application would not be able to use these objects because it serializes and deserializes objects differently than Java. <br /> <br /> Another approach you could take is to send a text file filled with data to the application that requests it. This is better because a C# application could read the data. But this has another flaw: Lets assume your stock application is not the only one the C# application needs to interact with. Maybe it needs weather data, local restaurant data, movie data, etc. If every one of these applications uses its own unique file format, it would take considerable research to get the C# application to a working state. <br /> <br /> The solution to both of these problems is to send a standard file format. A format that any application can use, regardless of the data being transported. Web Services are this solution. They let any application communicate with any other application without having to consider the language it was developed in or the format of the data. <br /> <br /> At the simplest level, web services can be seen as a specialized web application that differs mainly at the presentation tier level. While web applications typically are HTML-based, web services are XML-based. Interactive users for B2C (business to consumer) transactions normally access web applications, while web services are employed as building blocks by other web applications for forming B2B (business to business) chains using the so-called SOA model. Web services typically present a public functional interface, callable in a programmatic fashion, while web applications tend to deal with a richer set of features and are content-driven in most cases. <br /> <br /> == Securing Web Services ==<br /> <br /> Web services, like other distributed applications, require protection at multiple levels: <br /> <br /> *SOAP messages that are sent on the wire should be delivered confidentially and without tampering<br /> <br /> *The server needs to be confident who it is talking to and what the clients are entitled to<br /> <br /> *The clients need to know that they are talking to the right server, and not a phishing site (see the Phishing chapter for more information)<br /> <br /> *System message logs should contain sufficient information to reliably reconstruct the chain of events and track those back to the authenticated callers<br /> <br /> Correspondingly, the high-level approaches to solutions, discussed in the following sections, are valid for pretty much any distributed application, with some variations in the implementation details. <br /> <br /> The good news for Web Services developers is that these are infrastructure-level tasks, so, theoretically, it is only the system administrators who should be worrying about these issues. However, for a number of reasons discussed later in this chapter, WS developers usually have to be at least aware of all these risks, and oftentimes they still have to resort to manually coding or tweaking the protection components. <br /> <br /> == Communication security ==<br /> <br /> There is a commonly cited statement, and even more often implemented approach &quot;We are using SSL to protect all communication, we are secure&quot;. At the same time, there have been so many articles published on the topic of &quot;channel security vs. token security&quot; that it hardly makes sense to repeat those arguments here. Therefore, listed below is just a brief rundown of most common pitfalls when using channel security alone: <br /> <br /> *It provides only &quot;point-to-point&quot; security<br /> <br /> Any communication with multiple &quot;hops&quot; requires establishing separate channels (and trusts) between each communicating node along the way. There is also a subtle issue of trust transitivity, as trusts between node pairs {A,B} and {B,C} do not automatically imply {A,C} trust relationship. <br /> <br /> *Storage issue<br /> <br /> After messages are received on the server (even if it is not the intended recipient), they exist in the clear-text form, at least temporarily. Storing the transmitted information at the intermediate aggravates the problem or destination servers in log files (where it can be browsed by anybody) and local caches. <br /> <br /> *Lack of interoperability<br /> <br /> While SSL provides a standard mechanism for transport protection, applications then have to utilize highly proprietary mechanisms for transmitting credentials, ensuring freshness, integrity, and confidentiality of data sent over the secure channel. Using a different server, which is semantically equivalent, but accepts a different format of the same credentials, would require altering the client and prevent forming automatic B2B service chains. <br /> <br /> Standards-based token protection in many cases provides a superior alternative for message-oriented Web Service SOAP communication model. <br /> <br /> That said the reality is that the most Web Services today are still protected by some form of channel security mechanism, which alone might suffice for a simple internal application. However, one should clearly realize the limitations of such approach, and make conscious trade-offs at the design time, whether channel, token, or combined protection would work better for each specific case. <br /> <br /> == Passing credentials ==<br /> <br /> In order to enable credentials exchange and authentication for Web Services, their developers must address the following issues. <br /> <br /> First, since SOAP messages are XML-based, all passed credentials have to be converted to text format. This is not a problem for username/password types of credentials, but binary ones (like X.509 certificates or Kerberos tokens) require converting them into text prior to sending and unambiguously restoring them upon receiving, which is usually done via a procedure called Base64 encoding and decoding. <br /> <br /> Second, passing credentials carries an inherited risk of their disclosure, either by sniffing them during the wire transmission, or by analyzing the server logs. Therefore, things like passwords and private keys need to be either encrypted, or just never sent &quot;in the clear&quot;. Usual ways to avoid sending sensitive credentials are using cryptographic hashing and/or signatures. <br /> <br /> == Ensuring message freshness ==<br /> <br /> Even a valid message may present a danger if it is utilized in a &quot;replay attack&quot;. i.e. it is sent multiple times to the server to make it repeat the requested operation. This may be achieved by capturing an entire message, even if it is sufficiently protected against tampering, since it is the message itself that is used for attack now (see the XML Injection section of the Interpreter Injection chapter). <br /> <br /> Usual means to protect against replayed messages is either using unique identifiers (nonces) on messages and keeping track of processed ones, or using a relatively short validity time window. In the Web Services world, information about the message creation time is usually communicated by inserting timestamps, which may just tell the instant the message was created, or have additional information, like its expiration time, or certain conditions. <br /> <br /> The latter solution, although easier to implement, requires clock synchronization and is sensitive to server time skew, whereas server or clients' clocks drift too much, preventing timely message delivery, although this usually does not present significant problems with modern-day computers. A greater issue lies with message queuing at the servers, where messages may be expiring while waiting to be processed in the queue of an especially busy or non-responsive server. <br /> <br /> == Protecting message integrity ==<br /> <br /> When a message is received by a web service, it must always ask two questions: ¿whether I trust the caller?, ¿whether it created this message&amp;nbsp;?. Assuming that the caller trust has been established one way or another, the server has to be assured that the message it is looking at was indeed issued by the caller, and not altered along the way (intentionally or not). This may affect technical qualities of a SOAP message, such as the message's timestamp, or business content, such as the amount to be withdrawn from the bank account. Obviously, neither change should go undetected by the server. <br /> <br /> In communication protocols, there are usually some mechanisms like checksum applied to ensure packet's integrity. This would not be sufficient, however, in the realm of publicly exposed Web Services, since checksums (or digests, their cryptographic equivalents) are easily replaceable and cannot be reliably tracked back to the issuer. The required association may be established by utilizing HMAC, or by combining message digests with either cryptographic signatures or with secret key-encryption (assuming the keys are only known to the two communicating parties) to ensure that any change will immediately result in a cryptographic error. <br /> <br /> == Protecting message confidentiality ==<br /> <br /> Oftentimes, it is not sufficient to ensure the integrity; in many cases it is also desirable that nobody can see the data that is passed around and/or stored locally. It may apply to the entire message being processed, or only to certain parts of it; In either case, some type of encryption is required to conceal the content. Normally, symmetric encryption algorithms are used to encrypt bulk data, since it is significantly faster than the asymmetric ones. Asymmetric encryption is then applied to protect the symmetric session keys, which, in many implementations, are valid for one communication only and are subsequently discarded. <br /> <br /> Applying encryption requires conducting an extensive setup work, since the communicating parties now have to be aware of which keys they can trust, deal with certificate and key validation, and know which keys should be used for communication. <br /> <br /> In many cases, encryption is combined with signatures to provide both integrity and confidentiality. Normally, signing keys are different from the encrypting ones, primarily because of their different lifecycles, signing keys are permanently associated with their owners, while encryption keys may be invalidated after the message exchange. Another reason may be separation of business responsibilities - the signing authority (and the corresponding key) may belong to one department or person, while encryption keys are generated by the server controlled by members of IT department. <br /> <br /> == Access control ==<br /> <br /> After the message has been received and successfully validated, the server must decide: <br /> <br /> *Does it know who is requesting the operation (Identification)<br /> <br /> *Does it trust the caller's identity claim (Authentication)<br /> <br /> *Does it allow the caller to perform this operation (Authorization)<br /> <br /> There is not much WS-specific activity that takes place at this stage, just several new ways of passing the credentials for authentication. Most often, authorization (or entitlement) tasks occur completely outside of the Web Service implementation, at the Policy Server that protects the whole domain. <br /> <br /> There is another significant problem here, the traditional HTTP firewalls do not help at stopping attacks at the Web Services. An organization would need an XML/SOAP firewall, which is capable of conducting application-level analysis of the web server's traffic and make intelligent decision about passing SOAP messages to their destination. The reader would need to refer to other books and publications on this very important topic, as it is impossible to cover it within just one chapter. <br /> <br /> == Audit ==<br /> <br /> A common task, typically required from the audits, is reconstructing the chain of events that led to a certain problem. Normally, this would be achieved by saving server logs in a secure location, available only to the IT administrators and system auditors, in order to create what is commonly referred to as &quot;audit trail&quot;. Web Services are no exception to this practice, and follow the general approach of other types of Web Applications. <br /> <br /> Another auditing goal is non-repudiation, meaning that a message can be verifiably traced back to the caller. Following the standard legal practice, electronic documents now require some form of an &quot;electronic signature&quot;, but its definition is extremely broad and can mean practically anything, in many cases, entering your name and birthday qualifies as an e-signature. <br /> <br /> As far as the WS are concerned, such level of protection would be insufficient and easily forgeable. The standard practice is to require cryptographic digital signatures over any content that has to be legally binding, if a document with such a signature is saved in the audit log, it can be reliably traced to the owner of the signing key <br /> <br /> == Web Services Security Hierarchy ==<br /> <br /> Technically speaking, Web Services themselves are very simple and versatile, XML-based communication, described by an XML-based grammar, called Web Services Description Language (WSDL, see &lt;u&gt;http://www.w3.org/TR/2005/WD-wsdl20-20050510&lt;/u&gt;), which binds abstract service interfaces, consisting of messages, expressed as XML Schema, and operations, to the underlying wire format. Although it is by no means a requirement, the format of choice is currently SOAP over HTTP. This means that Web Service interfaces are described in terms of the incoming and outgoing SOAP messages, transmitted over HTTP protocol. <br /> <br /> === Standards committees ===<br /> <br /> Before reviewing the individual standards, it is worth taking a brief look at the organizations which are developing and promoting them. There are quite a few industry-wide groups and consortiums working in this area, most important of which are listed below. <br /> <br /> W3C (see &lt;u&gt;http://www.w3.org&lt;/u&gt;) is the most well known industry group, which owns many Web-related standards and develops them in Working Group format. Of particular interest to this chapter are XML Schema, SOAP, XML-dsig, XML-enc, and WSDL standards (called recommendations in the W3C's jargon). <br /> <br /> OASIS (see &lt;u&gt;http://www.oasis-open.org&lt;/u&gt;) mostly deals with Web Service-specific standards, not necessarily security-related. It also operates on a committee basis, forming so-called Technical Committees (TC) for the standards that it is going to be developing. Of interest for this discussion, OASIS owns WS-Security and SAML standards. <br /> <br /> Web Services Interoperability Organization (WS-I, see &lt;u&gt;http://www.ws-i.org/&lt;/u&gt;) was formed to promote a general framework for interoperable Web Services. Mostly its work consists of taking other broadly accepted standards, and developing so-called profiles, or sets of requirements for conforming Web Service implementations. In particular, its Basic Security Profile (BSP) relies on the OASIS' WS-Security standard and specifies sets of optional and required security features in Web Services that claim interoperability. <br /> <br /> Liberty Alliance (LA, see &lt;u&gt;http://projectliberty.org&lt;/u&gt;) consortium was formed to develop and promote an interoperable Identity Federation framework. Although this framework is not strictly Web Service-specific, but rather general, it is important for this topic because of its close relation with the SAML standard developed by OASIS. <br /> <br /> Besides the previously listed organizations, there are other industry associations, both permanently established and short-lived, which push forward various Web Service security activities. They are usually made up of software industry's leading companies, such as Microsoft, IBM, Verisign, BEA, Sun, and others, that join them to work on a particular issue or proposal. Results of these joint activities, once they reach certain maturity, are often submitted to standardizations committees as a basis for new industry standards. <br /> <br /> == SOAP ==<br /> <br /> Simple Object Access Protocol (SOAP, see &lt;u&gt;http://www.w3.org/TR/2003/REC-soap12-part1-20030624/&lt;/u&gt;) provides an XML-based framework for exchanging structured and typed information between peer services. This information, formatted into Header and Body, can theoretically be transmitted over a number of transport protocols, but only HTTP binding has been formally defined and is in active use today. SOAP provides for Remote Procedure Call-style (RPC) interactions, similar to remote function calls, and Document-style communication, with message contents based exclusively on XML Schema definitions in the Web Service's WSDL. Invocation results may be optionally returned in the response message, or a Fault may be raised, which is roughly equivalent to using exceptions in traditional programming languages. <br /> <br /> SOAP protocol, while defining the communication framework, provides no help in terms of securing message exchanges, the communications must either happen over secure channels, or use protection mechanisms described later in this chapter. <br /> <br /> === XML security specifications (XML-dsig &amp;amp; Encryption) ===<br /> <br /> XML Signature (XML-dsig, see &lt;u&gt;http://www.w3.org/TR/2002/REC-xmldsig-core-20020212&lt;/u&gt;/), and XML Encryption (XML-enc, see &lt;u&gt;http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/&lt;/u&gt;) add cryptographic protection to plain XML documents. These specifications add integrity, message and signer authentication, as well as support for encryption/decryption of whole XML documents or only of some elements inside them. <br /> <br /> The real value of those standards comes from the highly flexible framework developed to reference the data being processed (both internal and external relative to the XML document), refer to the secret keys and key pairs, and to represent results of signing/encrypting operations as XML, which is added to/substituted in the original document. <br /> <br /> However, by themselves, XML-dsig and XML-enc do not solve the problem of securing SOAP-based Web Service interactions, since the client and service first have to agree on the order of those operations, where to look for the signature, how to retrieve cryptographic tokens, which message elements should be signed and encrypted, how long a message is considered to be valid, and so on. These issues are addressed by the higher-level specifications, reviewed in the following sections. <br /> <br /> === Security specifications ===<br /> <br /> In addition to the above standards, there is a broad set of security-related specifications being currently developed for various aspects of Web Service operations. <br /> <br /> One of them is SAML, which defines how identity, attribute, and authorization assertions should be exchanged among participating services in a secure and interoperable way. <br /> <br /> A broad consortium, headed by Microsoft and IBM, with the input from Verisign, RSA Security, and other participants, developed a family of specifications, collectively known as &quot;Web Services Roadmap&quot;. Its foundation, WS-Security, has been submitted to OASIS and became an OASIS standard in 2004. Other important specifications from this family are still found in different development stages, and plans for their submission have not yet been announced, although they cover such important issues as security policies (WS-Policy et al), trust issues and security token exchange (WS-Trust), establishing context for secure conversation (WS-SecureConversation). One of the specifications in this family, WS-Federation, directly competes with the work being done by the LA consortium, and, although it is supposed to be incorporated into the Longhorn release of Windows, its future is not clear at the moment, since it has been significantly delayed and presently does not have industry momentum behind it. <br /> <br /> == WS-Security Standard ==<br /> <br /> WS-Security specification (WSS) was originally developed by Microsoft, IBM, and Verisign as part of a &quot;Roadmap&quot;, which was later renamed to Web Services Architecture, or WSA. WSS served as the foundation for all other specifications in this domain, creating a basic infrastructure for developing message-based security exchange. Because of its importance for establishing interoperable Web Services, it was submitted to OASIS and, after undergoing the required committee process, became an officially accepted standard. Current version is 1.1, and it was released on February 17, 2006.&lt;br&gt;<br /> <br /> The protocol is currently officially called WSS and developed via committee in Oasis-Open.&lt;br&gt;<br /> <br /> === Organization of the standard ===<br /> <br /> The WSS standard itself deals with several core security areas, leaving many details to so-called profile documents. The core areas, broadly defined by the standard, are: <br /> <br /> *Ways to add security headers (WSSE Header) to SOAP Envelopes<br /> <br /> *Attachment of security tokens and credentials to the message<br /> <br /> *Inserting a timestamp<br /> <br /> *Signing the message<br /> <br /> *Encrypting the message<br /> <br /> *Extensibility<br /> <br /> Flexibility of the WS-Security standard lies in its extensibility, so that it remains adaptable to new types of security tokens and protocols that are being developed. This flexibility is achieved by defining additional profiles for inserting new types of security tokens into the WSS framework. While the signing and encrypting parts of the standards are not expected to require significant changes (only when the underlying XML-dsig and XML-enc are updated), the types of tokens, passed in WSS messages, and ways of attaching them to the message may vary substantially. At the high level the WSS standard defines three types of security tokens, attachable to a WSS Header: Username/password, Binary, and XML tokens. Each of those types is further specified in one (or more) profile document, which defines additional tokens' attributes and elements, needed to represent a particular type of security token. <br /> <br /> [[Image:WSS Specification Hierarchy.gif|Figure 4: WSS specification hierarchy]] <br /> <br /> === Purpose ===<br /> <br /> The primary goal of the WSS standard is providing tools for message-level communication protection, whereas each message represents an isolated piece of information, carrying enough security data to verify all important message properties, such as: authenticity, integrity, freshness, and to initiate decryption of any encrypted message parts. This concept is a stark contrast to the traditional channel security, which methodically applies pre-negotiated security context to the whole stream, as opposed to the selective process of securing individual messages in WSS. In the Roadmap, that type of service is eventually expected to be provided by implementations of standards like WS-SecureConversation. <br /> <br /> From the beginning, the WSS standard was conceived as a message-level toolkit for securely delivering data for higher level protocols. Those protocols, based on the standards like WS-Policy, WS-Trust, and Liberty Alliance, rely on the transmitted tokens to implement access control policies, token exchange, and other types of protection and integration. However, taken alone, the WSS standard does not mandate any specific security properties, and an ad-hoc application of its constructs can lead to subtle security vulnerabilities and hard to detect problems, as is also discussed in later sections of this chapter. <br /> <br /> == WS-Security Building Blocks ==<br /> <br /> The WSS standard actually consists of a number of documents, one core document, which defines how security headers may be included into SOAP envelope and describes all high-level blocks, which must be present in a valid security header. Profile documents have the dual task of extending definitions for the token types they are dealing with, providing additional attributes, elements, as well as defining relationships left out of the core specification, such as using attachments. <br /> <br /> Core WSS 1.1 specification, located at &lt;u&gt;http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf&lt;/u&gt;, defines several types of security tokens (discussed later in this section: see 0), ways to reference them, timestamps, and ways to apply XML-dsig and XML-enc in the security headers, see the XML Dsig section for more details about their general structure. <br /> <br /> Associated specifications are: <br /> <br /> *Username token profile 1.1, located at &lt;u&gt;http://www.oasis-open.org/committees/download.php/16782/wss-v1.1-spec-os-UsernameTokenProfile.pdf&lt;/u&gt;, which adds various password-related extensions to the basic UsernameToken from the core specification<br /> <br /> *X.509 token profile 1.1, located at &lt;u&gt;http://www.oasis-open.org/committees/download.php/16785/wss-v1.1-spec-os-x509TokenProfile.pdf&lt;/u&gt; which specifies, how X.509 certificates may be passed in the BinarySecurityToken, specified by the core document<br /> <br /> *SAML Token profile 1.1, located at &lt;u&gt;http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf&lt;/u&gt; that specifies how XML-based SAML tokens can be inserted into WSS headers.<br /> <br /> *Kerberos Token Profile 1.1, located at &lt;u&gt;http://www.oasis-open.org/committees/download.php/16788/wss-v1.1-spec-os-KerberosTokenProfile.pdf&lt;/u&gt; that defines how to encode Kerberos tickets and attach them to SOAP messages.<br /> <br /> *Rights Expression Language (REL) Token Profile 1.1, located at &lt;u&gt;http://www.oasis-open.org/committees/download.php/16687/oasis-wss-rel-token-profile-1.1.pdf&lt;/u&gt; that describes the use of ISO/IEC 21000-5 Rights Expressions with respect to the WS-Security specification.<br /> <br /> *SOAP with Attachments (SWA) Profile 1.1, located at &lt;u&gt;http://www.oasis-open.org/committees/download.php/16672/wss-v1.1-spec-os-SwAProfile.pdf&lt;/u&gt; that describes how to use WSS-Sec with SOAP Messages with Attachments.<br /> <br /> === How data is passed ===<br /> <br /> WSS security specification deals with two distinct types of data: security information, which includes security tokens, signatures, digests, etc; and message data, i.e. everything else that is passed in the SOAP message. Being an XML-based standard, WSS works with textual information grouped into XML elements. Any binary data, such as cryptographic signatures or Kerberos tokens, has to go through a special transform, called Base64 encoding/decoding, which provides straightforward conversion from binary to ASCII formats and back. The example below demonstrates how binary data looks like in the encoded format: <br /> <br /> &lt;br&gt; <br /> <br /> ''cCBDQTAeFw0wNDA1MTIxNjIzMDRaFw0wNTA1MTIxNjIzMDRaMG8xCz'' <br /> <br /> &lt;br&gt; <br /> <br /> After encoding a binary element, an attribute with the algorithm's identifier is added to the XML element carrying the data, so that the receiver would know to apply the correct decoder to read it. These identifiers are defined in the WSS specification documents. <br /> <br /> === Security header's structure ===<br /> <br /> A security header in a message is used as a sort of an envelope around a letter, it seals and protects the letter, but does not care about its content. This &quot;indifference&quot; works in the other direction as well, as the letter (SOAP message) should not know, nor should it care about its envelope (WSS Header), since the different units of information, carried on the envelope and in the letter, are presumably targeted at different people or applications. <br /> <br /> A SOAP Header may actually contain multiple security headers, as long as they are addressed to different actors (for SOAP 1.1), or roles (for SOAP 1.2). Their contents may also be referring to each other, but such references present a very complicated logistical problem for determining the proper order of decryptions/signature verifications, and should generally be avoided. WSS security header itself has a loose structure, as the specification itself does not require any elements to be present; so, the minimalist header with an empty message will look like: <br /> <br /> &lt;br&gt; <br /> <br /> &amp;lt;soap:Envelope xmlns:soap=&quot;http://schemas.xmlsoap.org/soap/envelope/&quot;&amp;gt;<br /> &amp;lt;soap:Header&amp;gt;<br /> &amp;lt;wsse:Security xmlns:wsse=&quot;http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd&quot; xmlns:wsu=&quot;http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd&quot; soap:mustUnderstand=&quot;1&quot;&amp;gt;<br /> <br /> &amp;lt;/wsse:Security&amp;gt;<br /> &amp;lt;/soap:Header&amp;gt;<br /> &amp;lt;soap:Body&amp;gt;<br /> <br /> &amp;lt;/soap:Body&amp;gt;<br /> &amp;lt;/soap:Envelope&amp;gt;<br /> <br /> &lt;br&gt; <br /> <br /> However, to be useful, it must carry some information, which is going to help securing the message. It means including one or more security tokens (see 0) with references, XML Signature, and XML Encryption elements, if the message is signed and/or encrypted. So, a typical header will look more like the following picture: <br /> <br /> &lt;br&gt; <br /> <br /> &amp;lt;soap:Envelope xmlns:soap=&quot;http://schemas.xmlsoap.org/soap/envelope/&quot;&amp;gt;<br /> &amp;lt;soap:Header&amp;gt;<br /> &amp;lt;wsse:Security xmlns=&quot;http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd&quot; xmlns:wsse=&quot;http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd&quot; xmlns:wsu=&quot;http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd&quot; soap:mustUnderstand=&quot;1&quot;&amp;gt;<br /> &amp;lt;wsse:BinarySecurityToken EncodingType=&quot;http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary&quot; ValueType=&quot;http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3&quot; wsu:Id=&quot;aXhOJ5&quot;&amp;gt;MIICtzCCAi... <br /> &amp;lt;/wsse:BinarySecurityToken&amp;gt;<br /> &amp;lt;xenc:EncryptedKey xmlns:xenc=&quot;http://www.w3.org/2001/04/xmlenc#&quot;&amp;gt;<br /> &amp;lt;xenc:EncryptionMethod Algorithm=&quot;http://www.w3.org/2001/04/xmlenc#rsa-1_5&quot;/&amp;gt;<br /> &amp;lt;dsig:KeyInfo xmlns:dsig=&quot;http://www.w3.org/2000/09/xmldsig#&quot;&amp;gt;<br /> &amp;lt;wsse:SecurityTokenReference&amp;gt;<br /> &amp;lt;wsse:Reference URI=&quot;#aXhOJ5&quot; ValueType=&quot;http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3&quot;/&amp;gt;<br /> &amp;lt;/wsse:SecurityTokenReference&amp;gt; <br /> &amp;lt;/dsig:KeyInfo&amp;gt;<br /> &amp;lt;xenc:CipherData&amp;gt;<br /> &amp;lt;xenc:CipherValue&amp;gt;Nb0Mf...&amp;lt;/xenc:CipherValue&amp;gt;<br /> &amp;lt;/xenc:CipherData&amp;gt;<br /> &amp;lt;xenc:ReferenceList&amp;gt;<br /> &amp;lt;xenc:DataReference URI=&quot;#aDNa2iD&quot;/&amp;gt;<br /> &amp;lt;/xenc:ReferenceList&amp;gt;<br /> &amp;lt;/xenc:EncryptedKey&amp;gt;<br /> &amp;lt;wsse:SecurityTokenReference wsu:Id=&quot;aZG0sG&quot;&amp;gt;<br /> &amp;lt;wsse:KeyIdentifier ValueType=&quot;http://docs.oasis-open.org/wss/2004/XX/oasis-2004XX-wss-saml-token-profile-1.0#SAMLAssertionID&quot; wsu:Id=&quot;a2tv1Uz&quot;&amp;gt; 1106844369755&amp;lt;/wsse:KeyIdentifier&amp;gt;<br /> &amp;lt;/wsse:SecurityTokenReference&amp;gt;<br /> &amp;lt;saml:Assertion AssertionID=&quot;1106844369755&quot; IssueInstant=&quot;2005-01-27T16:46:09.755Z&quot; Issuer=&quot;www.my.com&quot; MajorVersion=&quot;1&quot; MinorVersion=&quot;1&quot; xmlns:saml=&quot;urn:oasis:names:tc:SAML:1.0:assertion&quot;&amp;gt;<br /> ... <br /> &amp;lt;/saml:Assertion&amp;gt;<br /> &amp;lt;wsu:Timestamp wsu:Id=&quot;afc6fbe-a7d8-fbf3-9ac4-f884f435a9c1&quot;&amp;gt;<br /> &amp;lt;wsu:Created&amp;gt;2005-01-27T16:46:10Z&amp;lt;/wsu:Created&amp;gt;<br /> &amp;lt;wsu:Expires&amp;gt;2005-01-27T18:46:10Z&amp;lt;/wsu:Expires&amp;gt;<br /> &amp;lt;/wsu:Timestamp&amp;gt;<br /> &amp;lt;dsig:Signature xmlns:dsig=&quot;http://www.w3.org/2000/09/xmldsig#&quot; Id=&quot;sb738c7&quot;&amp;gt;<br /> &amp;lt;dsig:SignedInfo Id=&quot;obLkHzaCOrAW4kxC9az0bLA22&quot;&amp;gt;<br /> ...<br /> &amp;lt;dsig:Reference URI=&quot;#s91397860&quot;&amp;gt;<br /> ... <br /> &amp;lt;dsig:DigestValue&amp;gt;5R3GSp+OOn17lSdE0knq4GXqgYM=&amp;lt;/dsig:DigestValue&amp;gt;<br /> &amp;lt;/dsig:Reference&amp;gt;<br /> &amp;lt;/dsig:SignedInfo&amp;gt;<br /> &amp;lt;dsig:SignatureValue Id=&quot;a9utKU9UZk&quot;&amp;gt;LIkagbCr5bkXLs8l...&amp;lt;/dsig:SignatureValue&amp;gt;<br /> &amp;lt;dsig:KeyInfo&amp;gt;<br /> &amp;lt;wsse:SecurityTokenReference&amp;gt;<br /> &amp;lt;wsse:Reference URI=&quot;#aXhOJ5&quot; ValueType=&quot;http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3&quot;/&amp;gt;<br /> &amp;lt;/wsse:SecurityTokenReference&amp;gt;<br /> &amp;lt;/dsig:KeyInfo&amp;gt;<br /> &amp;lt;/dsig:Signature&amp;gt;<br /> &amp;lt;/wsse:Security&amp;gt;<br /> &amp;lt;/soap:Header&amp;gt;<br /> &amp;lt;soap:Body xmlns:wsu=&quot;http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd&quot; wsu:Id=&quot;s91397860&quot;&amp;gt;<br /> &amp;lt;xenc:EncryptedData xmlns:xenc=&quot;http://www.w3.org/2001/04/xmlenc#&quot; Id=&quot;aDNa2iD&quot; Type=&quot;http://www.w3.org/2001/04/xmlenc#Content&quot;&amp;gt;<br /> &amp;lt;xenc:EncryptionMethod Algorithm=&quot;http://www.w3.org/2001/04/xmlenc#tripledes-cbc&quot;/&amp;gt;<br /> &amp;lt;xenc:CipherData&amp;gt;<br /> &amp;lt;xenc:CipherValue&amp;gt;XFM4J6C...&amp;lt;/xenc:CipherValue&amp;gt;<br /> &amp;lt;/xenc:CipherData&amp;gt;<br /> &amp;lt;/xenc:EncryptedData&amp;gt;<br /> &amp;lt;/soap:Body&amp;gt;<br /> &amp;lt;/soap:Envelope&amp;gt;<br /> <br /> === Types of tokens ===<br /> <br /> A WSS Header may have the following types of security tokens in it: <br /> <br /> *Username token<br /> <br /> Defines mechanisms to pass username and, optionally, a password - the latter is described in the username profile document. Unless the whole token is encrypted, a message which includes a clear-text password should always be transmitted via a secured channel. In situations where the target Web Service has access to clear-text passwords for verification (this might not be possible with LDAP or some other user directories, which do not return clear-text passwords), using a hashed version with nonce and a timestamp is generally preferable. The profile document defines an unambiguous algorithm for producing password hash: <br /> <br /> Password_Digest = Base64 ( SHA-1 ( nonce + created + password ) )<br /> <br /> *Binary token<br /> <br /> They are used to convey binary data, such as X.509 certificates, in a text-encoded format, Base64 by default. The core specification defines BinarySecurityToken element, while profile documents specify additional attributes and sub-elements to handle attachment of various tokens. Presently, both the X.509 and the Kerberos profiles have been adopted. <br /> <br /> &lt;br&gt; <br /> <br /> &amp;lt;wsse:BinarySecurityToken EncodingType=&quot;http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary&quot; ValueType=&quot;http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3&quot; wsu:Id=&quot;aXhOJ5&quot;&amp;gt;<br /> MIICtzCCAi...<br /> &amp;lt;/wsse:BinarySecurityToken&amp;gt;<br /> <br /> &lt;br&gt; <br /> <br /> *XML token<br /> <br /> These are meant for any kind of XML-based tokens, but primarily, for SAML assertions. The core specification merely mentions the possibility of inserting such tokens, leaving all details to the profile documents. At the moment, SAML 1.1 profile has been accepted by OASIS. <br /> <br /> &lt;br&gt; <br /> <br /> &amp;lt;saml:Assertion AssertionID=&quot;1106844369755&quot; IssueInstant=&quot;2005-01-27T16:46:09.755Z&quot; Issuer=&quot;www.my.com&quot; MajorVersion=&quot;1&quot; MinorVersion=&quot;1&quot; xmlns:saml=&quot;urn:oasis:names:tc:SAML:1.0:assertion&quot;&amp;gt;<br /> ... <br /> &amp;lt;/saml:Assertion&amp;gt;<br /> <br /> &lt;br&gt; <br /> <br /> Although technically it is not a security token, a Timestamp element may be inserted into a security header to ensure message's freshness. See the further reading section for a design pattern on this. <br /> <br /> === Referencing message parts ===<br /> <br /> In order to retrieve security tokens, passed in the message, or to identify signed and encrypted message parts, the core specification adopts usage of a special attribute, wsu:Id. The only requirement on this attribute is that the values of such IDs should be unique within the scope of XML document where they are defined. Its application has a significant advantage for the intermediate processors, as it does not require understanding of the message's XML Schema. Unfortunately, XML Signature and Encryption specifications do not allow for attribute extensibility (i.e. they have closed schema), so, when trying to locate signature or encryption elements, local IDs of the Signature and Encryption elements must be considered first. <br /> <br /> WSS core specification also defines a general mechanism for referencing security tokens via SecurityTokenReference element. An example of such element, referring to a SAML assertion in the same header, is provided below: <br /> <br /> &lt;br&gt; <br /> <br /> &amp;lt;wsse:SecurityTokenReference wsu:Id=&quot;aZG0sGbRpXLySzgM1X6aSjg22&quot;&amp;gt;<br /> &amp;lt;wsse:KeyIdentifier ValueType=&quot;http://docs.oasis-open.org/wss/2004/XX/oasis-2004XX-wss-saml-token-profile-1.0#SAMLAssertionID&quot; wsu:Id=&quot;a2tv1Uz&quot;&amp;gt;<br /> 1106844369755<br /> &amp;lt;/wsse:KeyIdentifier&amp;gt;<br /> &amp;lt;/wsse:SecurityTokenReference&amp;gt;<br /> <br /> &lt;br&gt; <br /> <br /> As this element was designed to refer to pretty much any possible token type (including encryption keys, certificates, SAML assertions, etc) both internal and external to the WSS Header, it is enormously complicated. The specification recommends using two of its possible four reference types: Direct References (by URI) and Key Identifiers (some kind of token identifier). Profile documents (SAML, X.509 for instance) provide additional extensions to these mechanisms to take advantage of specific qualities of different token types. <br /> <br /> == Communication Protection Mechanisms ==<br /> <br /> As was already explained earlier (see 0), channel security, while providing important services, is not a panacea, as it does not solve many of the issues facing Web Service developers. WSS helps addressing some of them at the SOAP message level, using the mechanisms described in the sections below. <br /> <br /> === Integrity ===<br /> <br /> WSS specification makes use of the XML-dsig standard to ensure message integrity, restricting its functionality in certain cases; for instance, only explicitly referenced elements can be signed (i.e. no Embedding or Embedded signature modes are allowed). Prior to signing an XML document, a transformation is required to create its canonical representation, taking into account the fact that XML documents can be represented in a number of semantically equivalent ways. There are two main transformations defined by the XML Digital Signature WG at W3C, Inclusive and Exclusive Canonicalization Transforms (C14N and EXC-C14N), which differ in the way namespace declarations are processed. The WSS core specification specifically recommends using EXC-C14N, as it allows copying signed XML content into other documents without invalidating the signature. <br /> <br /> In order to provide a uniform way of addressing signed tokens, WSS adds a Security Token Reference (STR) Dereference Transform option, which is comparable with dereferencing a pointer to an object of specific data type in programming languages. Similarly, in addition to the XML Signature-defined ways of addressing signing keys, WSS allows for references to signing security tokens through the STR mechanism (explained in 0), extended by token profiles to accommodate specific token types. A typical signature example is shown in an earlier sample in the section 0. <br /> <br /> Typically, an XML signature is applied to secure elements such as SOAP Body and the timestamp, as well as any user credentials, passed in the request. There is an interesting twist when a particular element is both signed and encrypted, since these operations may follow (even repeatedly) in any order, and knowledge of their ordering is required for signature verification. To address this issue, the WSS core specification requires that each new element is pre-pended to the security header, thus defining the &quot;natural&quot; order of operations. A particularly nasty problem arises when there are several security headers in a single SOAP message, using overlapping signature and encryption blocks, as there is nothing in this case that would point to the right order of operations. <br /> <br /> === Confidentiality ===<br /> <br /> For its confidentiality protection, WSS relies on yet another standard, XML Encryption. Similarly to XML-dsig, this standard operates on selected elements of the SOAP message, but it then replaces the encrypted element's data with a &amp;lt;xenc:EncryptedData&amp;gt; sub-element carrying the encrypted bytes. For encryption efficiency, the specification recommends using a unique key, which is then encrypted by the recipient's public key and pre-pended to the security header in a &amp;lt;xenc:EncryptedKey&amp;gt; element. A SOAP message with encrypted body is shown in the section 0. <br /> <br /> === Freshness ===<br /> <br /> SOAP messages' freshness is addressed via timestamp mechanism, each security header may contain just one such element, which states, in UTC time and using the UTC time format, creation and expiration moments of the security header. It is important to realize that the timestamp is applied to the WSS Header, not to the SOAP message itself, since the latter may contain multiple security headers, each with a different timestamp. There is an unresolved problem with this &quot;single timestampt&quot; approach, since, once the timestamp is created and signed, it is impossible to update it without breaking existing signatures, even in case of a legitimate change in the WSS Header. <br /> <br /> &amp;lt;wsu:Timestamp wsu:Id=&quot;afc6fbe-a7d8-fbf3-9ac4-f884f435a9c1&quot;&amp;gt;<br /> &amp;lt;wsu:Created&amp;gt;2005-01-27T16:46:10Z&amp;lt;/wsu:Created&amp;gt;<br /> &amp;lt;wsu:Expires&amp;gt;2005-01-27T18:46:10Z&amp;lt;/wsu:Expires&amp;gt;<br /> &amp;lt;/wsu:Timestamp&amp;gt;<br /> <br /> If a timestamp is included in a message, it is typically signed to prevent tampering and replay attacks. There is no mechanism foreseen to address clock synchronization issue (which, as was already point out earlier, is generally not an issue in modern day systems), this has to be addressed out-of-band as far as the WSS mechanics is concerned. See the further reading section for a design pattern addressing this issue. <br /> <br /> == Access Control Mechanisms ==<br /> <br /> When it comes to access control decisions, Web Services do not offer specific protection mechanisms by themselves, they just have the means to carry the tokens and data payloads in a secure manner between source and destination SOAP endpoints. <br /> <br /> For more complete description of access control tasks, please, refer to other sections of this Development Guide. <br /> <br /> === Identification ===<br /> <br /> Identification represents a claim to have certain identity, which is expressed by attaching certain information to the message. This can be a username, an SAML assertion, a Kerberos ticket, or any other piece of information, from which the service can infer who the caller claims to be. <br /> <br /> WSS represents a very good way to convey this information, as it defines an extensible mechanism for attaching various token types to a message (see 0). It is the receiver's job to extract the attached token and figure out which identity it carries, or to reject the message if it can find no acceptable token in it. <br /> <br /> === Authentication ===<br /> <br /> Authentication can come in two flavors: credentials verification or token validation. The subtle difference between the two is that tokens are issued after some kind of authentication has already happened prior to the current invocation, and they usually contain user's identity along with the proof of its integrity. <br /> <br /> WSS offers support for a number of standard authentication protocols by defining binding mechanism for transmitting protocol-specific tokens and reliably linking them to the sender. However, the mechanics of proof that the caller is who he claims to be is completely at the Web Service's discretion. Whether it takes the supplied username and password's hash and checks it against the backend user store, or extracts subject name from the X.509 certificate used for signing the message, verifies the certificate chain and looks up the user in its store, at the moment, there are no requirements or standards which would dictate that it should be done one way or another. <br /> <br /> === Authorization ===<br /> <br /> XACML may be used for expressing authorization rules, but its usage is not Web Service-specific, it has much broader scope. So, whatever policy or role-based authorization mechanism the host server already has in place will most likely be utilized to protect the deployed Web Services deployed as well. <br /> <br /> Depending on the implementation, there may be several layers of authorization involved at the server. For instance, JSRs 224 (JAX-RPC 2.0) and 109 (Implementing Enterprise Web Services), which define Java binding for Web Services, specify implementing Web Services in J2EE containers. This means that when a Web Service is accessed, there will be a URL authorization check executed by the J2EE container, followed by a check at the Web Service layer for the Web Service-specific resource. Granularity of such checks is implementation-specific and is not dictated by any standards. In the Windows universe it happens in a similar fashion, since IIS is going to execute its access checks on the incoming HTTP calls before they reach the ASP.NET runtime, where SOAP message is going to be further decomposed and analyzed. <br /> <br /> === Policy Agreement ===<br /> <br /> Normally, Web Services communication is based on the endpoint's public interface, defined in its WSDL file. This descriptor has sufficient details to express SOAP binding requirements, but it does not define any security parameters, leaving Web Service developers struggling to find out-of-band mechanisms to determine the endpoint's security requirements. <br /> <br /> To make up for these shortcomings, WS-Policy specification was conceived as a mechanism for expressing complex policy requirements and qualities, sort of WSDL on steroids. Through the published policy SOAP endpoints can advertise their security requirements, and their clients can apply appropriate measures of message protection to construct the requests. The general WS-Policy specification (actually comprised of three separate documents) also has extensions for specific policy types, one of them,&amp;nbsp; for security, WS-SecurityPolicy. <br /> <br /> If the requestor does not possess the required tokens, it can try obtaining them via trust mechanism, using WS-Trust-enabled services, which are called to securely exchange various token types for the requested identity. <br /> <br /> [[Image:Using Trust Service.gif|Figure 5. Using Trust service]] <br /> <br /> Unfortunately, both WS-Policy and WS-Trust specifications have not been submitted for standardization to public bodies, and their development is progressing via private collaboration of several companies, although it was opened up for other participants as well. As a positive factor, there have been several interoperability events conducted for these specifications, so the development process of these critical links in the Web Services' security infrastructure is not a complete black box. <br /> <br /> == Forming Web Service Chains ==<br /> <br /> Many existing or planned implementations of SOA or B2B systems rely on dynamic chains of Web Services for accomplishing various business specific tasks, from taking the orders through manufacturing and up to the distribution process. <br /> <br /> [[Image:Service Chain.gif|Figure 6: Service chain]] <br /> <br /> This is in theory. In practice, there are a lot of obstacles hidden among the way, and one of the major ones among them, security concerns about publicly exposing processing functions to intra- or Internet-based clients. <br /> <br /> Here are just a few of the issues that hamper Web Services interaction, incompatible authentication and authorization models for users, amount of trust between services themselves and ways of establishing such trust, maintaining secure connections, and synchronization of user directories or otherwise exchanging users' attributes. These issues will be briefly tackled in the following paragraphs. <br /> <br /> === Incompatible user access control models ===<br /> <br /> As explained earlier, in section 0, Web Services themselves do not include separate extensions for access control, relying instead on the existing security framework. What they do provide, however, are mechanisms for discovering and describing security requirements of a SOAP service (via WS-Policy), and for obtaining appropriate security credentials via WS-Trust based services. <br /> <br /> === Service trust ===<br /> <br /> In order to establish mutual trust between client and service, they have to satisfy each other's policy requirements. A simple and popular model is mutual certificate authentication via SSL, but it is not scalable for open service models, and supports only one authentication type. Services that require more flexibility have to use pretty much the same access control mechanisms as with users to establish each other's identities prior to engaging in a conversation. <br /> <br /> === Secure connections ===<br /> <br /> Once trust is established it would be impractical to require its confirmation on each interaction. Instead, a secure client-server link is formed and maintained the entire time a client's session is active. Again, the most popular mechanism today for maintaining such link is SSL, but it is not a Web Service-specific mechanism, and it has a number of shortcomings when applied to SOAP communication, as explained in 0. <br /> <br /> === Synchronization of user directories ===<br /> <br /> This is a very acute problem when dealing with cross-domain applications, as users' population tends to change frequently among different domains. So, how does a service in domain B decide whether it is going to trust user's claim that he has been already authenticated in domain A? There exist different aspects of this problem. First, a common SSO mechanism, which implies that a user is known in both domains (through synchronization, or by some other means), and authentication tokens from one domain are acceptable in another. In Web Services world, this would be accomplished by passing around a SAML or Kerberos token for a user. <br /> <br /> === Domain federation ===<br /> <br /> Another aspect of the problem is when users are not shared across domains, but merely the fact that a user with certain ID has successfully authenticated in another domain, as would be the case with several large corporations, which would like to form a partnership, but would be reluctant to share customers' details. The decision to accept this request is then based on the inter-domain procedures, establishing special trust relationships and allowing for exchanging such opaque tokens, which would be an example of Federation relationships. Of those efforts, most notable example is Liberty Alliance project, which is now being used as a basis for SAML 2.0 specifications. The work in this area is still far from being completed, and most of the existing deployments are nothing more than POC or internal pilot projects than to real cross-companies deployments, although LA's website does list some case studies of large-scale projects. <br /> <br /> == Available Implementations ==<br /> <br /> It is important to realize from the beginning that no security standard by itself is going to provide security to the message exchanges, it is the installed implementations, which will be assessing conformance of the incoming SOAP messages to the applicable standards, as well as appropriately securing the outgoing messages. <br /> <br /> === .NET Web Service Extensions ===<br /> <br /> Since new standards are being developed at a rather quick pace, .NET platform is not trying to catch up immediately, but uses Web Service Extensions (WSE) instead. WSE, currently at the version 2.0, adds development and runtime support for the latest Web Service security standards to the platform and development tools, even while they are still &quot;work in progress&quot;. Once standards mature, their support is incorporated into new releases of the .NET platform, which is what is going to happen when .NET 2.0 finally sees the world. The next release of WSE, 3.0, is going to coincide with VS.2005 release and will take advantages of the latest innovations of .NET 2.0 platform in messaging and Web Application areas. <br /> <br /> Considering that Microsoft is one of the most active players in the Web Service security area and recognizing its influence in the industry, its WSE implementation is probably one of the most complete and up to date, and it is strongly advisable to run at least a quick interoperability check with WSE-secured .NET Web Service clients. If you have a Java-based Web Service, and the interoperability is a requirement (which is usually the case), in addition to the questions of security testing one needs to keep in mind the basic interoperability between Java and .NET Web Service data structures. <br /> <br /> This is especially important since current versions of .NET Web Service tools frequently do not cleanly handle WS-Security's and related XML schemas as published by OASIS, so some creativity on the part of a Web Service designer is needed. That said, WSE package itself contains very rich and well-structured functionality, which can be utilized both with ASP.NET-based and standalone Web Service clients to check incoming SOAP messages and secure outgoing ones at the infrastructure level, relieving Web Service programmers from knowing these details. Among other things, WSE 2.0 supports the most recent set of WS-Policy and WS-Security profiles, providing for basic message security and WS-Trust with WS-SecureConversation. Those are needed for establishing secure exchanges and sessions - similar to what SSL does at the transport level, but applied to message-based communication. <br /> <br /> === Java toolkits ===<br /> <br /> Most of the publicly available Java toolkits work at the level of XML security, i.e. XML-dsig and XML-enc, such as IBM's XML Security Suite and Apache's XML Security Java project. Java's JSR 105 and JSR 106 (still not finalized) define Java bindings for signatures and encryption, which will allow plugging the implementations as JCA providers once work on those JSRs is completed. <br /> <br /> Moving one level up, to address Web Services themselves, the picture becomes muddier, at the moment, there are many implementations in various stages of incompleteness. For instance, Apache is currently working on the WSS4J project, which is moving rather slowly, and there is commercial software package from Phaos (now owned by Oracle), which suffers from a lot of implementation problems. <br /> <br /> A popular choice among Web Service developers today is Sun's JWSDP, which includes support for Web Service security. However, its support for Web Service security specifications in the version 1.5 is only limited to implementation of the core WSS standard with username and X.509 certificate profiles. Security features are implemented as part of the JAX-RPC framework and configuration-driven, which allows for clean separation from the Web Service's implementation. <br /> <br /> === Hardware, software systems ===<br /> <br /> This category includes complete systems, rather than toolkits or frameworks. On one hand, they usually provide rich functionality right off the shelf, on the other hand, its usage model is rigidly constrained by the solution's architecture and implementation. This is in contrast to the toolkits, which do not provide any services by themselves, but handing system developers necessary tools to include the desired Web Service security features in their products' or to shoot themselves in the foot by applying them inappropriately. <br /> <br /> These systems can be used at the infrastructure layer to verify incoming messages against the effective policy, check signatures, tokens, etc, before passing them on to the target Web Service. When applied to the outgoing SOAP messages, they act as a proxy, now altering the messages to decorate with the required security elements, sign and/or encrypt them. <br /> <br /> Software systems are characterized by significant configuration flexibility, but comparatively slow processing. On the bright side, they often provide high level of integration with the existing enterprise infrastructure, relying on the back-end user and policy stores to look at the credentials, extracted from the WSS header, from the broader perspective. An example of such service is TransactionMinder from the former Netegrity, a Policy Enforcement Point for Web Services behind it, layered on top of the Policy Server, which makes policy decisions by checking the extracted credentials against the configured stores and policies. <br /> <br /> For hardware systems, performance is the key, they have already broken gigabyte processing threshold, and allow for real-time processing of huge documents, decorated according to the variety of the latest Web Service security standards, not only WSS. The usage simplicity is another attractive point of those systems - in the most trivial cases, the hardware box may be literally dropped in, plugged, and be used right away. These qualities come with a price, however, this performance and simplicity can be achieved as long as the user stays within the pre-configured confines of the hardware box. The moment he tries to integrate with the back-end stores via callbacks (for those solutions that have this capability, since not all of them do), most of the advantages are lost. As an example of such hardware device, Layer 7 Technologies provides a scalable SecureSpan Networking Gateway, which acts both as the inbound firewall and the outbound proxy to handle XML traffic in real time. <br /> <br /> == Problems ==<br /> <br /> As is probably clear from the previous sections, Web Services are still experiencing a lot of turbulence, and it will take a while before they can really catch on. Here is a brief look at what problems surround currently existing security standards and their implementations. <br /> <br /> === Immaturity of the standards ===<br /> <br /> Most of the standards are either very recent (couple years old at most), or still being developed. Although standards development is done in committees, which, presumably, reduces risks by going through an exhaustive reviewing and commenting process, some error scenarios still slip in periodically, as no theory can possibly match the testing resulting from pounding by thousands of developers working in the real field. <br /> <br /> Additionally, it does not help that for political reasons some of these standards are withheld from public process, which is the case with many standards from the WSA arena (see 0), or that some of the efforts are duplicated, as was the case with LA and WS-Federation specifications. <br /> <br /> === Performance ===<br /> <br /> XML parsing is a slow task, which is an accepted reality, and SOAP processing slows it down even more. Now, with expensive cryptographic and textual conversion operations thrown into the mix, these tasks become a performance bottleneck, even with the latest crypto- and XML-processing hardware solutions offered today. All of the products currently on the market are facing this issue, and they are trying to resolve it with varying degrees of success. <br /> <br /> Hardware solutions, while substantially (by orders of magnitude) improving the performance, cannot always be used as an optimal solution, as they cannot be easily integrated with the already existing back-end software infrastructure, at least, not without making performance sacrifices. Another consideration whether hardware-based systems are the right solution, they are usually highly specialized in what they are doing, while modern Application Servers and security frameworks can usually offer a much greater variety of protection mechanisms, protecting not only Web Services, but also other deployed applications in a uniform and consistent way. <br /> <br /> === Complexity and interoperability ===<br /> <br /> As could be deduced from the previous sections, Web Service security standards are fairly complex, and have very steep learning curve associated with them. Most of the current products, dealing with Web Service security, suffer from very mediocre usability due to the complexity of the underlying infrastructure. Configuring all different policies, identities, keys, and protocols takes a lot of time and good understanding of the involved technologies, as most of the times errors that end users are seeing have very cryptic and misleading descriptions. <br /> <br /> In order to help administrators and reduce security risks from service misconfigurations, many companies develop policy templates, which group together best practices for protecting incoming and outgoing SOAP messages. Unfortunately, this work is not currently on the radar of any of the standard's bodies, so it appears unlikely that such templates will be released for public use any time soon. Closest to this effort may be WS-I's Basic Security Profile (BSP), which tries to define the rules for better interoperability among Web Services, using a subset of common security features from various security standards like WSS. However, this work is not aimed at supplying the administrators with ready for deployment security templates matching the most popular business use cases, but rather at establishing the least common denominator. <br /> <br /> === Key management ===<br /> <br /> Key management usually lies at the foundation of any other security activity, as most protection mechanisms rely on cryptographic keys one way or another. While Web Services have XKMS protocol for key distribution, local key management still presents a huge challenge in most cases, since PKI mechanism has a lot of well-documented deployment and usability issues. Those systems that opt to use homegrown mechanisms for key management run significant risks in many cases, since questions of storing, updating, and recovering secret and private keys more often than not are not adequately addressed in such solutions. <br /> <br /> == Further Reading ==<br /> <br /> *SearchSOA, SOA needs practical operational governance, Toufic Boubez<br /> <br /> &lt;u&gt;http://searchsoa.techtarget.com/news/interview/0,289202,sid26_gci1288649,00.html?track=NL-110&amp;amp;ad=618937&amp;amp;asrc=EM_NLN_2827289&amp;amp;uid=4724698&lt;/u&gt; <br /> <br /> *Whitepaper: Securing XML Web Services: XML Firewalls and XML VPNs<br /> <br /> &lt;u&gt;http://forms.layer7tech.com/content/Download?docid=1114&amp;amp;docname=Securing%20XML%20Web%20Services:%20SSL,%20XML%20Firewalling,%20and%20Beyond&lt;/u&gt; <br /> <br /> *eBizQ, The Challenges of SOA Security, Peter Schooff<br /> <br /> &lt;u&gt;http://www.ebizq.net/blogs/news_security/2008/01/the_complexity_of_soa_security.php&lt;/u&gt; <br /> <br /> *Piliptchouk, D., WS-Security in the Enterprise, O'Reilly ONJava<br /> <br /> &lt;u&gt;http://www.onjava.com/pub/a/onjava/2005/02/09/wssecurity.html&lt;/u&gt; <br /> <br /> &lt;u&gt;http://www.onjava.com/pub/a/onjava/2005/03/30/wssecurity2.html&lt;/u&gt; <br /> <br /> *WS-Security OASIS site<br /> <br /> &lt;u&gt;http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss&lt;/u&gt; <br /> <br /> *Microsoft, ''What's new with WSE 3.0''<br /> <br /> &lt;u&gt;http://msdn.microsoft.com/webservices/webservices/building/wse/default.aspx?pull=/library/en-us/dnwse/html/newwse3.asp&lt;/u&gt; <br /> <br /> *Eoin Keary, Preventing DOS attacks on web services<br /> <br /> &lt;u&gt;https://www.threatsandcountermeasures.com/wiki/default.aspx/ThreatsAndCountermeasuresCommunityKB.PreventingDOSAttacksOnWebServices&lt;/u&gt;&lt;br&gt; <br /> <br /> == Reference ==<br /> <br /> [[Guide Table of Contents|Development Guide Table of Contents]] <br /> <br /> [[Category:FIXME|broken link]] [[Category:OWASP_Guide_Project]] [[Category:Web_Services]]</div>

Jorge Correa https://wiki.owasp.org/index.php?title=Talk:Top_10_2004&diff=108810 2011-04-14T14:07:19Z

<p>Jorge Correa: Created page with &quot;It's necessary to change the link to the last version of top ten, because It's pointing to the 2007 version and should point to 2010 version.&quot;</p> <hr /> <div>It's necessary to change the link to the last version of top ten, because It's pointing to the 2007 version and should point to 2010 version.</div>

Jorge Correa https://wiki.owasp.org/index.php?title=Diez_Mayores_2007&diff=85089 2010-06-17T21:41:25Z

<p>Jorge Correa: </p> <hr /> <div>{{Top_10_2007:TopTemplate|usenext=NextLink|next=-Metodología|useprev=Nothing|usemain=Nothing}}<br /> <br /> ==Presentación==<br /> <br /> Bienvenidos a la lista de las 10 mayores vulnerabilidades de OWASP 2007! Esta edición, totalmente reescrita lista las vulnerabilidades más serias en aplicaciones web, discute como protegerse de ellas y provee ligas a mas información. '''La lista de las 10 mayores vulnerabilidades de OWASP ha sido traducida al Español. [https://www.owasp.org/images/a/ae/OWASP_Top_10_2007_Spanish.pdf De clic aquí] para la traducción al español!'''<br /> <br /> La lista de las 10 mayores de OWASP para la versión empresarial de Java esta disponible para bajarla [https://www.owasp.org/images/8/89/OWASP_Top_10_2007_for_JEE.pdf aqui]<br /> <br /> == Objetivo ==<br /> <br /> '''El objetivo principal de la lista de las 10 de OWASP es formar desarrolladores, diseñadores, arquitectos y organizaciones''' sobre las consecuencias de las vulnerabilidades más comunes en aplicaciones web. Las lista provee métodos básicos para protegerse contra estas vulnerabilidades - un gran inicio para su programa de codificación segura.<br /> <br /> '''La seguridad no es un evento de una sola vez'''. No es suficiente asegurar su código solo una vez. Para 2008, esta lista cambiará y sin cambiar una línea de el código de su aplicación, puede ser vulnerable. Por favor revise el consejo en [[Top_10_2007-Where to Go From Here|Top 10 2007-¿A dondé sigo Ahora?]] para mas información.<br /> <br /> '''Una iniciativa de codificación segura debe lidiar con todas las etapas de desarrollo del programa'''. Las aplicaciones Web seguras '''''solo''''' es posible cuando un SDLC seguro es usado. Los programas seguros desde el inicio por su diseño y desarrollo. Hay al menos 300 problemas que afectan la seguridad en general de una aplicación Web. Estos mas de 300 problemas están detallados en la [http://www.owasp.org/index.php/OWASP_Guide_Project Guía de OWASP], la cua es una lectura escencial para cualquiera que desarolle aplicaciones Web en la actualidad.<br /> <br /> '''Este documento es el principalmente un documento educativo, no un standard'''. Por favor no adopte este documento como una política o estándar sin [mailto:owasp@owasp.org hablar con nosotros] primero! Si necesita una política o estandar de codificación segura, OWASP tiene proyectos de políticas y estándares de seguridad que están en progreso. Por favor considere unirse o asistir financieramente estos esfuerzos.<br /> <br /> == Retroalimentación ==<br /> <br /> {| <br /> |-<br /> <br /> |Agradecemos a [http://www.mitre.org/ MITRE] por hacer ''La distribución de tipos de vulnerabilidades en el [http://cve.mitre.org/ CVE]'' disponibles libremente para su uso. El proyecto de la lista de las 10 mayores esta dirijida y patrocinada por [http://www.aspectsecurity.com https://www.owasp.org/images/d/d1/Aspect_logo.gif].<br /> |}<br /> <br /> Líder de proyecto: Andrew van der Stock (Director ejecutivo, Fundación OWASP)<br /> Co-autores: Jeff Williams (Presidencia, Fundación OWASP), Dave Wichers (Presidencia de conferencia, Fundación OWASP)<br /> <br /> Queremos agradecer a los revisores:<br /> <br /> *Raoul Endres por ayudar a echar a andar la lista de nuevo y por sus valiosos comentarios.<br /> *[mailto:coley...at...mitre.org Steve Christey](MITRE) por una importante revisión y la adición de los datos del MITRE CWE<br /> *[http://jeremiahgrossman.blogspot.com/ Jeremiah Grossman] ([http://www.whitehatsec.com/ WhiteHat Security]) por revisar y contribuir con información sobre el éxico (o falla) de la medidas de detección automatizadas.<br /> *[http://www.smithline.net/ Neil Smithline] ([http://www.bea.com/ BEA Systems]) por sus comentarios y producir la versión Wiki-<br /> *Sylvan von Stuppe por una revisión ejemplar.<br /> *Colin Wong, Nigel Evans y Andre Gironda por comentarios enviados por correo.<br /> <br /> == Conclusión ==<br /> <br /> {| border='1' cellpadding='2' <br /> |- <br /> |[[Top 10 2007-Secuencia de Comandos en Sitios Cruzados (XSS)|A1 - Secuencia de comandos en sitios cruzados (XSS)]]<br /> |Las fallas de XSS acurren cuando una aplicación toma la información proveida por el usuario y la envia a un navegador sin validarla primero o codificar el contenido. El XSS permite a los atacantes ejecurar scripts en el navegador de la víctima la cual puede secuestrar la sesión del usuario, modificación de sitios web, la posible introducción de gusanos, etc.<br /> |-<br /> <br /> |[[Top 10 2007-Fallas de Inyección|A2 - Inyección de código]]<br /> |La fallas de inyección, particularmente la inyección de SQL, son comunes en las aplicaciones Web. La inyección ocurre cuando los datos proveidos por el usuario son enviados a un interprete como parte de un comando o petición. Los datos hostiles del atacante engañan al interprete a ejecutar comandos no intencionados o cambiar los datos.<br /> |-<br /> <br /> |[[Top 10 2007-Ejecución de Ficheros Malintencionados|A3 - Ejecución maliciosa de archivos]]<br /> |El código vulnerable a inclusión remota de archivos permite a los atacantes incluir código y datos hostiles, resultando en ataques devastadores, como secuestro total del servidor. Los ataques de ejecución maliciosa de archivos afectan a PHP, XML y cualquier marco de trabajo que soporte el manejo de nombres de archivos o permita la interacción con los usuarios mediante el intercambio de archivos.<br /> |-<br /> <br /> |[[Top 10 2007-Referencia Insegura y Directa a Objetos|A4 - Referencia directa e insegura a objetos]]<br /> |Una referencia directa e insegura a objetos ocurre cuando un desarrollador expone una referencia a una implementación interna de un objeto como unn archivo, un directorio, un registro de BD o una llave, en forma de parámetro de URL o de una forma. Los atacantes pueden manipular esas referencias para acceder a otros objetos sin tener autorización<br /> |-<br /> <br /> |[[Top 10 2007-Vulnerabilidades de Falsificación de Petición en Sitios Cruzados (CSRF)|A5 - Falsificación de petición en sitios crusados (CSRF)]]<br /> |A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.<br /> <br /> |-<br /> <br /> |[[Top 10 2007-Revelación de Información y Gestión Incorrecta de Errores|A6 - Revelación de Información y Gestión Incorrecta de Errores]]<br /> |Las aplicaciones pueden (sin intención) revelar información sobre su configuración, funcionalidad interna o violar la privacidad a travez de una variedad de problemas de la aplicación. Los atacantes usan estas debilidades para robar información delicada o conducir ataques mas serios. <br /> |-<br /> <br /> |[[Top 10 2007-Autenticación y Gestión de Sesiones Disfuncional|A7 - Autentificación y gestión de sesiones disfuncional]]<br /> |Las credenciales de las cuenta y testigos de sesión son frecuentemente protegidos inadecuadamente. Los atacantes roban contraseñas, llaves o testigos de autneticación para asumir la identidad de otros usuarios.<br /> |-<br /> <br /> |[[Top 10 2007-Almacenamiento Criptográfico Inseguro|A8 - Almacenamiento cirptográfico inseguro]]<br /> |Las aplicaciones Web raramente usan funciones criptográdicas apropiadamente para proteger información y credenciales. Los atacantes usan la información mal protegida para hacer robos de identidad y otros crimenes, como fraude con tarjetas de crédito.<br /> |-<br /> <br /> |[[Top 10 2007-Comunicaciones inseguras|A9 - Comunicación Insegura]]<br /> |Las aplicaciones frecuentement falla al cifrar el tráfico de red cuando es necesario proteger comunicaciones delicadas.<br /> |-<br /> <br /> |[[Top 10 2007-Falla de restricción de acceso a URL|A10 - Falla de restricción de acceso a URL]]<br /> |Frecuentemente, una aplicacion solo protege funcionalidad delicada evitando mostrar la ligas o URLs a usuarios no autorizados. Los atacantes pueden usar esta debilidad para acceder y realizar operaciones no autorizadas al acceder a esas URLs directamente.<br /> |}<br /> '''&lt;center&gt;Tabla 1: La 10 mayores vulnerabilidades de OWASP 2007&lt;/center&gt;'''<br /> <br /> <br /> Hay muchas páginas en este documento que no están dedicadas a vulnerabilidades en específico y por lo tanto no están listadas en la tabla. Aqui hay una lista de ellas.<br /> <br /> {| border='1' cellpadding='2' <br /> |- <br /> |[[Top 10 2007]]<br /> |Ademas de proveer una presentación, y un marcador de la sección de &quot;conclusiones&quot; (esto puede hacerse arrastrando [https://www.owasp.org/index.php/Top_10_2007#Summary este enlace] a sus favoritos) nos da acceso rápido a el documento completo.<br /> |-<br /> |[[Top 10 2007-Metodología]]<br /> |Una descripción de la metodología usada para selecionar las vulnerabilidades para este documento.<br /> |-<br /> |[[Top 10 2007-¿A dondé sigo Ahora?]]<br /> |Algunas sugerencias sobre como proceder una ves que ha leído este documento.<br /> |-<br /> |[[Top 10 2007-Referencias]]<br /> |Recomendaciones para lectura posterior.<br /> |}<br /> '''&lt;center&gt;Tabla 1a: Paginas en el documento de la ''lista de las 10 mayores 2007'' que no son la lista de vulnerabilidades mencionadas arriba.&lt;/center&gt;'''<br /> <br /> ==Una nota sobre las diferentes versiones==<br /> Mientras que la única versión oficial de la ''lista de las 10 mayores vulnerabilidades de OWASP 2007'' es la version en PDF y en inglés, OWASP ah puesto a su disposición este Wiki que inicialmente contenia el mismo contenido que el PDF. Pero OWASP espera que cambien con su ayuda. OWASP promueve el envolvimiento de la comunidad y quiere su ayuda para hacer la versión Wiki mejor que nunca. Para ayudar a esto han creado un pequeño [[Editing:Top_10_2007|tutorial]] para iniciarlo en este proceso.<br /> <br /> ==Versiones para bajar==<br /> Puede bajar la lista 2007 (versión final) aqui:<br /> <br /> * [http://www.owasp.org/images/e/e8/OWASP_Top_10_2007.pdf (PDF, 930 kb)]<br /> &lt;!--* [http://www.owasp.org/images/2/24/OWASP_Top_10_2007.doc (Word, 514 kb)]--&gt;<br /> <br /> * [https://www.owasp.org/images/a/ae/OWASP_Top_10_2007_Spanish.pdf (Español PDF, 488kb)]<br /> <br /> * [https://www.owasp.org/images/c/ce/OWASP_Top_10_2007_-_French.pdf (Francés PDF, 455 kb)]<br /> <br /> * [http://www.metasecurity.org/owasp/OWASP_Top_10_2007_Korean.pdf (Koreano PDF, 768 kb)]<br /> <br /> * [http://csirt.ulakbim.gov.tr/dokumanlar/Ceviri_OWASP_ilk10_2007.pdf (Turco PDF, 718 kb)]<br /> <br /> * [http://www.owasp.org/images/4/42/OWASP_TOP_10_2007_PT-BR.pdf (Portuguese Brasileño PDF, 329 kb)]<br /> <br /> * [https://www.owasp.org/images/8/89/OWASP_Top_10_2007_for_JEE.pdf OWASP Top 10 para la versión empresarial de Java (PDF, 630 kb)]<br /> <br /> * Le gustaría tener esta versión en otro idioma? podriamos usar su ayuda para traducirla. Contacte a Andrew van der Stock (vanderaj ...(@)... owasp.org) para ayudarnos a traducir la lista de las 10 mayores a otro idioma.<br /> <br /> {{Top_10_2007:BottomTemplate|usenext=NextLink|next=-Metodología|useprev=Nothing|usemain=Nothing}}</div>

Jorge Correa https://wiki.owasp.org/index.php?title=OWASP_JBroFuzz_Tutorial&diff=83957 2010-05-26T16:47:59Z

<p>Jorge Correa: /* Introduction */</p> <hr /> <div>&lt;br&gt; <br /> <br /> == Introduction ==<br /> <br /> ''“If you can’t fuzz with JBroFuzz, you probably do not want to fuzz!”'' <br /> &lt;div align=&quot;right&quot;&gt;Old JBroFuzz Motto &lt;/div&gt; <br /> &lt;br&gt; The art of teaching, Mark Van Doren said, is the art of assisting discovery. Fuzzing is a representative discipline towards assisting the discovery of security vulnerabilities, that is just beginning to come of age. Over the last two years, through continuous development, JBroFuzz has attempted to expose the intrinsic beauty of the subject: Constantly submit a vast amount of payloads to a service, device or prompt, waiting for the one response that makes all the difference. This is the mentality that JBroFuzz embraces and attempts to offer back to security professionals. <br /> <br /> Fuzzing as a concept goes beyond a conventional work flow or a standard methodology. I would argue that to know how to fuzz well, is to master a new language. Thus, similar to the process of learning a programming (or foreign) language, there are three things you must master: <br /> <br /> • Grammar: How fuzzing as a process is structured&lt;br&gt; • Vocabulary: How to name fuzzing concepts you want to use&lt;br&gt; • Usage: Ways of achieving everyday effective results with fuzzing&lt;br&gt; <br /> <br /> [[Image:001-JBroFuzz-Tutorial.jpg|right|300px|JBroFuzz Splash Screen]]From the pre-existing information available for JBroFuzz, this tutorial focuses on usage: How to best put a fuzzing tool to good use, either via the UI, or using APIs that ''JBroFuzz.jar'' is constituted of. As a result, this document has a small requirement as a caveat; you need to have a beginner level understanding of the Java programming language in order to understand some sections. <br /> <br /> There are a number of working examples described here within, which '''grep''' for statements such as “''&lt;nowiki&gt;public static void main(String[] args)&lt;/nowiki&gt;''”. The majority of the content relates to reviewing these examples and putting the Java syntax into a fuzzing perspective. <br /> <br /> To summarise, this tutorial focuses on customary and effective usage of fuzzing through the JBroFuzz Java APIs and the respective UI. It is targeting (without attacking them) web applications. Without further redo, let’s get fuzzing!<br /> <br /> == JBroFuzz Basic Functionality ==<br /> <br /> This section carries a number of basic fuzzing examples to get you started with JBroFuzz. Overall, even though the actions performed to not produce any amazing fuzzing results, it serves as a starting point in understanding how to perform particular fuzzing operations on web applications. <br /> <br /> === 'Hello Google!' (forget 'Hello World') ===<br /> <br /> As the traditional first program that you learn when indulging in a new programming language, 'Hello World!' represents the norm for understanding the basic output operations and syntax (let alone compiler and execution behaviour) of the language in question. <br /> <br /> As with most web application security related tools, when I am given the responsibility to run them, often in order to understand how they work, I would first craft a legitimate, single request to a trusted (to be up and behaving) popular Internet location. Needless, to say this request more than on occasion finds itself on Google servers. <br /> <br /> So 'Hello World!' for programming languages seems to transform to 'Hello Google!' for understanding how web application security related tools work. Let us see, how JBroFuzz does it. <br /> <br /> • Double-click on JBroFuzz and browse to the 'Fuzzing' tab <br /> <br /> JBroFuzz is constituted of tabs, typically located in the bottom or top (if you bother to change the settings) of the main window. <br /> <br /> The 'Fuzzing' tab is where you craft your request message to a particular host. Once that is in place, you can select any part of the request and proceed into adding any number of payloads. We shall see how in later sections. <br /> <br /> • In the 'URL' field type: http://www.google.com/ http://www.google.com <br /> <br /> Unlike conventional URLs, the URL field in JBroFuzz is only used for the underlying protocol (HTTP or HTTPS), host name (e.g. www.yahoo.com) and (optionally) port number. <br /> <br /> All remaining information pasted or typed into the 'URL' field will be ignored; you are expected to enter it in the 'Request' field below. <br /> <br /> &lt;nowiki&gt;Still, if you want to just copy-paste a URL from a browser, hit [Ctrl+L] while you are not fuzzing, paste the URL value that you have copied from a browser and JBroFuzz will automatically do the work for you. &lt;/nowiki&gt; <br /> <br /> Examples of valid URL values to be put in the <br /> <br /> Treat the 'URL' and 'Request' fields as the two stages of a 'telnet' session on port 80; you are effectively using the 'URL' field to specify the equivalent of: <br /> <br /> &lt;tt&gt;&amp;gt;telnet www.google.com 8088&lt;/tt&gt; <br /> <br /> As equivalent to: <br /> <br /> &lt;code&gt;http://www.google.com:8088&lt;br&gt; &lt;/code&gt; <br /> <br /> or in the case of HTTPS: <br /> <br /> &lt;code&gt;https://www.google.com:8088&lt;br&gt; &lt;/code&gt; <br /> <br /> Naturally, default ports for HTTP is 80 and HTTPS is 443. <br /> <br /> • In the 'Request' field type: <br /> <br /> &lt;code&gt;GET / HTTP/1.0&lt;br&gt; &lt;br&gt; &lt;/code&gt; <br /> <br /> And press 'Enter' twice <br /> <br /> This is where the body of the message you are sending is to be placed. So anything obeying HTTP/S protocol, such as GET and POST requests, header fields and/or HTML content should be included here. <br /> <br /> As part of the process of fuzzing web applications with JBroFuzz you need to have done your homework, in terms of providing a base request message. This message is what will be used later on to add payloads to particular sections of the request. <br /> <br /> &lt;nowiki&gt;• Hit 'Start' [Ctrl+Enter]&lt;/nowiki&gt; <br /> <br /> This will instigate the process of sending a single request to the specified host on a given (or default) port, over HTTP or HTTPS. <br /> <br /> Once a connection has been established JBroFuzz will proceed to submit the message you have typed into the 'Request' field. <br /> <br /> Finally, JBroFuzz will log all data sent and received into a file; accessing this file is typically a process of double clicking on the output line on the table at the bottom section of the 'Fuzzing' tab. <br /> <br /> You should see a response received in the bottom part of the 'Fuzzing' panel. Double click (or right click for more options) to see the information exchanged; typically this would be a 302 redirect pointing you to another location. Congratulations, you have just said &quot;Hello&quot; to Google! <br /> <br /> [[Image:002-JBroFuzz-Tutorial.png|500px|JBroFuzz Hello Google!]] <br /> <br /> Now this would typically be enough under RFC rules, to get a response back; but damn all the bots out here, most websites require further information to respond back. So, in the 'Request' field let's pretend to be a (kind of) legitimate browser by typing: <br /> <br /> &lt;code&gt;GET / HTTP/1.0&lt;br&gt; Host: www.google.com&lt;br&gt; User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729) JBroFuzz/1.5&lt;br&gt; Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-gb,en;q=0.5Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7&lt;br&gt; &lt;br&gt; &lt;/code&gt; <br /> <br /> Not forgetting to end the request typed with two returns: Press 'Enter' twice. Again, you should be able to see a line added with the response received back. <br /> <br /> Practice sending single requests to a website of your choice by changing the URL and also the 'Host:' field from the 'Request' above. Also try accessing an HTTPS website. <br /> <br /> &lt;nowiki&gt;Alternatively, you can use the shortcut [Ctrl+L] to type in your URL, with the 'Request' field filled automatically, based on the URL you have typed. &lt;/nowiki&gt; &lt;br&gt; <br /> <br /> === HTTP Version Numbers &amp;amp; www.cia.gov Headerless Responses ===<br /> <br /> For web applications, very often ill-defined requests submitted over the Internet, will trigger semi-legitimate responses that actually do not obey HTTP RFC protocol specification. Often, even though this is not the case in this example, these responses can lead to the identification of one or more security vulnerabilities. <br /> <br /> In this example we test for the responses received for invalid HTTP version numbers on a particular website, namely www.cia.gov, over https. Now a word of caution here; please do not attempt to fuzz web applications that you do not have the authority to do so, especially over the Internet. <br /> <br /> Still, for the purposes of this tutorial exercise, we will subject a web server to no more than a dozen or so requests. These requests would be otherwise identical, if it was not for the HTTP version number incrementing by a value of 1 on each request. <br /> <br /> In terms of having the authority to do so, well this is identical to hitting 'Refresh' in your web browser a dozen or so times, while you are browsing to www.cia.gov. I do not consider this remotely close to any form of hacking, cracking, or proper fuzzing; web servers across the globe receive a lot more abuse than this on a daily basis. <br /> <br /> Finally, by the time you are reading this, the particular issue described might have been fixed. So here goes: <br /> <br /> • Within JBroFuzz, select: <br /> <br /> &lt;code&gt;File -&amp;gt; Open Location [Ctrl+L]&lt;br&gt; &lt;/code&gt; <br /> <br /> Type: https://www.cia.gov and hit enter. This is depicted in the following screenshot: <br /> <br /> [[Image:003-JBroFuzz-Tutorial.png|JBroFuzz Open Location]] <br /> <br /> Hitting 'Enter' should automatically populate the 'URL' field and the 'Request' field within the 'Fuzzing' tab. What you see is the base request that we intend to add fuzzing payloads to. Before we do so, let us make one small alteration first: <br /> <br /> • Modify the first line of the 'Request' field to: <br /> <br /> &lt;code&gt;GET / HTTP/0.0&lt;br&gt; &lt;/code&gt; <br /> <br /> Our objective is to enumerate the supported by the web server (in this case www.cia.gov) HTTP version numbers, following the two digit format that it has. We could be a lot more agressive here and test for buffer overflows and all types of injection; that would be out of line without the authority to do so. Instead we are going to see how JBroFuzz will iterate through the values of 0.0 to 1.4 by means of adding a Fuzzer to our base request. <br /> <br /> • Highlight the second zero from the line 'GET / HTTP/0.0' and right-click, selecting 'Add'. This is depicted in the screeshot below: <br /> <br /> [[Image:004-JBroFuzz-Tutorial.png|400px|Adding a Fuzzer to the HTTP version number]] <br /> <br /> • From the appearing 'Add a Fuzzer' window, select as 'Category Name', in the most left column 'Base' and as 'Fuzzer Name' in the middle column 'Base 10 (Decimal) Alphabet. <br /> <br /> • Click on 'Add Fuzzer' on the bottom right of the window <br /> <br /> [[Image:005-JBroFuzz-Tutorial.png|400px|Adding a Fuzzer]] <br /> <br /> This should add a Fuzzer of length 1 that iterates over the decimal (i.e. base 10) numbers 0 to 9. If we have added a hexadecimal Fuzzer instead of a decimal one (i.e. base 16) the iteration would from 0 to F. If we had selected two digits instead of one and proceeded to add a decimal Fuzzer, the iteration would be from: <br /> <br /> &lt;code&gt;00&lt;br&gt; 01&lt;br&gt; ..&lt;br&gt; 98&lt;br&gt; 99&lt;br&gt; &lt;/code&gt; <br /> <br /> From a User Interface (UI) perspective you should see a line added to the 'Added Payloads Table'. <br /> <br /> • Click 'Start' [Ctrl+Enter] <br /> <br /> This process will send 10 requests to the specified web server changing only first line of the request to: <br /> <br /> &lt;code&gt;GET / HTTP/0.0...&lt;br&gt; GET / HTTP/0.1...&lt;br&gt; ...&lt;br&gt; GET / HTTP/0.8...&lt;br&gt; GET / HTTP/0.9...&lt;br&gt; &lt;/code&gt; <br /> <br /> While this is ongoing, you can sort the results by 'No' in the 'Output' table in the bottom of the 'Fuzzing' tab. This should enable you to see what request is currently being transmitted and received in real time. <br /> <br /> Once complete, change the first line of the 'Request' field to read: <br /> <br /> &lt;code&gt;GET / HTTP/1.0&lt;br&gt; &lt;/code&gt; <br /> <br /> • Click 'Start' [Ctrl+Enter] <br /> <br /> The resulting output should resemble the following screenshot: <br /> <br /> [[Image:006-JBroFuzz-Tutorial.png|500px|JBroFuzz Output from a Fuzzing Session]] <br /> <br /> Straight away we can notice a difference in the response size: For HTTP version numbers 0.0 to 0.9 we are getting back what seems fairly big in size responses; 32222 bytes in size worth of responses, given that HTTP protocol version 0.0 to 0.8 do not officially exist! <br /> <br /> By double-clicking on one of these requests, we can see that the web server in question is responding back with no headers, yet returning a full HTML body; this represents the 32222 bytes of response of data we are receiving back. The following screenshot illustrates this: <br /> <br /> [[Image:007-JBroFuzz-Tutorial.png|300px|JBroFuzz Output for a Single Request/Response]] <br /> <br /> Using the 'Graphing' tab we can proceed to graph the particular requests and responses for this given session. <br /> <br /> • Within the 'Graphing' tab, click 'Start' [Ctrl+Enter]. <br /> <br /> • Select the directory corresponding to the Output folder we have used for this fuzzing session. This will typically be the last one. <br /> <br /> • Right-click and select 'Graph' <br /> <br /> Once complete, browse to the 'Response Size' tab within the 'Graphing' tab, as illustrated in the screenshot below: <br /> <br /> [[Image:008-JBroFuzz-Tutorial.png|300px|JBroFuzz Graphing different 'Response Sizes']] <br /> <br /> To re-iterate this does not present a security vulnerability in any shape or form; merely the fact that by manipulating HTTP version numbers as part of the request we transmit, we can impact the response that we get back. In this case, what changes is the non-existent header fields, with some HTML content being received back. <br /> <br /> If I was to guess what is causing this, I would say that some sort of load balancing or content delivery is not happening as it should when non-existent version numbers are being transmitted. <br /> <br /> == Using JBroFuzz with a Generic Proxy ==<br /> <br /> JBrofuzz 2.0 and subsequent releases include generic proxy support. As of this writing, basic authentication is supported with plans to eventually support NTLM and Kerberos authentication as well. We've tried to make the use of a proxy as straight forward as possible. All arguments for the proxy can be passed in the URL field and will take one of the following forms. <br /> &lt;pre&gt;Without Authentication: &amp;lt;proxy server&amp;gt;:&amp;lt;proxy port&amp;gt;<br /> With Authentication: &amp;lt;proxy username&amp;gt;:&amp;lt;proxy password&amp;gt;@&amp;lt;proxy server&amp;gt;:&amp;lt;proxy port&amp;gt;<br /> &lt;/pre&gt; <br /> The structure of the request field and whether the GET parameter contains an absolute URL depends on the proxy you are using. For this reason, you may have to do a bit of trial and error to determine what format(s) your proxy accepts. To make all of this a bit clearer lets look at a couple of examples. <br /> <br /> === Squid Proxy ===<br /> <br /> In the first example, we are fuzzing through a squid proxy that requires ncsa user authentication as shown in the figure below. When producing similar results, its important that you use your own proxy and not the one shown in the figure. This proxy was setup for demonstration purposes, will not accept connections from your IP address, and the credentials will no longer be active. <br /> <br /> [[Image:016-JBroFuzz-Tutorial.jpg|503x449px]] <br /> <br /> === Paros Proxy ===<br /> <br /> In the second example, we are fuzzing through a local Paros proxy running on port 8080 that does not require user authentication. Notice the difference in the syntax of the URL field when user authentication is not required. <br /> <br /> [[Image:017-JBroFuzz-Tutorial.jpg|503x449px]] <br /> <br /> In the third example, we are still fuzzing through Paros, but notice the slight difference in the Request Field. Specifically, pay special attention to the GET line. We are no longer including the fully qualified path. Unlike Squid, Paros will accept both formats. Keep this in mind when you are performing initial testing with JBroFuzz and the proxy of your choice. <br /> <br /> [[Image:018-JBroFuzz-Tutorial.jpg|503x449px]]<br /> <br /> === Burp Proxy ===<br /> In the final example, we are fuzzing through Burp. Similar to Squid, Burp requires absolute URLs in the request. A successful Burp request is shown below.<br /> <br /> [[Image:019-JBroFuzz-Tutorial.jpg|503x449px]]<br /> <br /> == Using JBroFuzz with Paros Proxy ==<br /> <br /> JBroFuzz is a standalone fuzzer; it can release and create sockets over HTTP and HTTPS, but in order to use JBroFuzz correctly you will have to know what it is that you are fuzzing. <br /> <br /> In comes the need for a proxy tool; the opening versions of JBroFuzz actually had a proxy tab that you could use to intercept traffic generated by your web browser. That functionality got removed in an attempt to focus and deliver solely on the fuzzing capabilities of the tool. <br /> <br /> This section details how to use JBroFuzz in combination with a client side proxy. The one selected is Paros Proxy, which, despite the fact that it hasn't been updated since 2006 is still a popular tool that you see in web security testing live CDs. You could use any of the other proxy tools available. <br /> <br /> === Winning on a Remix of the Year Award ===<br /> <br /> At 17:53, on a frosty winter evening, a message window popped up: <br /> &lt;pre&gt;17:53 http://www.localhost.com/remixcontest/club/annual2010.html<br /> 17:53 Hey bro, could you cast in a vote here for the Such &amp;amp; Such Remix?<br /> 17:53 Appreciated!<br /> &lt;/pre&gt; <br /> A friend in need is a friend indeed, so here goes I thought. Opening up a web browser configured to work with Paros as an intermediate proxy, allowed for the casting of my vote. while keeping a record of each request and reply. <br /> <br /> No registration, or any other form of submitting an identifier was needed. The request that Paros stored for the casting of the actual vote was: <br /> &lt;pre&gt;GET http://www.localhost.com/remixcontest/club/vote.php?onLoad=%5Btype%20Method%5D&amp;amp;id=55 HTTP/1.1<br /> Host: www.localhost.com<br /> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729) Paros/3.2.13<br /> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8<br /> Accept-Language: en-gb,en;q=0.5<br /> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7<br /> Keep-Alive: 300<br /> Proxy-Connection: keep-alive<br /> Cookie: PHPSESSID=ab6afb883dbgf8084f6dcf1eafdb225e<br /> &lt;/pre&gt; <br /> Paros Proxy actually places the domain (in this case www.localhost.com) with the protocol (i.e. http) in front of the GET request. As a result, you can't open a telnet/netcat session and just copy-paste the above. Similarly when we bring the request into JBroFuzz, a bit of tweaking is required. <br /> <br /> *In the URL field, type:<br /> &lt;pre&gt;http://www.localhost.com<br /> &lt;/pre&gt; <br /> In the Request field, let's keep what is of interest: <br /> &lt;pre&gt;GET /remixcontest/club/vote.php?onLoad=%5Btype%20Method%5D&amp;amp;id=55 HTTP/1.0<br /> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5<br /> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8<br /> Accept-Language: en-gb,en;q=0.5<br /> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7<br /> Cookie: PHPSESSID=ab6afb883dbgf8084f6dcf1eafdb225e<br /> &lt;/pre&gt; <br /> No needs for Keep-Alive and Proxy-Connection. Let's simplify the HTTP request by making it a version 1.0 request and getting rid of the Host header as well. Also on the user agent, let us keep that mainstream vanilla: Firefox on Windows (popular browser combination), getting rid of the .NET and Paros additives. <br /> <br /> Checking on the website, our Such &amp;amp; Such remix already has about 100 votes or so and the top remix has approximately 310 votes. Let's fuzz this: <br /> <br /> *Select 2 of the digits of the cookie value:<br /> &lt;pre&gt;PHPSESSID=ab6afb883dbgf8084f6dcf1eafdb225e<br /> &lt;/pre&gt; <br /> *Select: Panel -&amp;gt; Add<br /> <br /> *In the &quot;Add a Fuzzer&quot; panel, select:<br /> &lt;pre&gt;Base -&amp;gt; Base16 (HEX)<br /> &lt;/pre&gt; <br /> and select &quot;Add Fuzzer&quot;. <br /> <br /> This will add a line within the Payloads tab on the right hand side. <br /> <br /> Our cookie value above (PHPSESSID=ab6afb883dbgf8084f6dcf1eafdb225e) is in lowercase, hexadecimal format. Let's make sure the encoding we select is also that. <br /> <br /> Within the Payloads tab, click on the encoding drop down menu and select lowercase. Just before clicking &quot;Start&quot;, JBroFuzz should look something like the screenshot below. <br /> <br /> [[Image:014-JBroFuzz-Tutorial.png|Adding Votes by iterating through PHPSESSID cookie values]] <br /> <br /> == Performing User Enumeration with a Valid Set of Credentials ==<br /> <br /> Often you encounter an application that allows for the enumeration of one or more pages after a user has been successfully granted a set of session credentials. One of the key areas to test from an application specific perspective, relates to the page(s) that provide user account information. <br /> <br /> In the following example, we investigate an ASP.NET 2.0 application with a C# back-end. In this, an authenticated user has the option to select to &quot;View My Profile&quot;. This page provides them with account information (including the typical username, email address, further notes) that they can proceed to update and save to the back-end system. <br /> <br /> After a user has authenticated, the following URL, gives them access to their profile information stored on the database: <br /> &lt;pre&gt;http://www.myattackingdomain.com/portal-location/UserInfo.aspx?UserID=23<br /> &lt;/pre&gt; <br /> Simple investigation confirms that the digits allowed as part of the UserID value are decimal numbers only. Lets feed that information into JBroFuzz. <br /> <br /> === Fuzzing a User ID ===<br /> <br /> • Within JBroFuzz, select: <br /> <br /> &lt;code&gt;File -&amp;gt; Open Location [Ctrl+L]&lt;br&gt; &lt;/code&gt; <br /> <br /> Type: http://www.myattackingdomain.com/portal-location/UserInfo.aspx?UserID=23 and hit enter. This is depicted in the following screenshot: <br /> <br /> [[Image:009-JBroFuzz-Tutorial.png|300px|JBroFuzz 'GET' Request with a 'UserID' parameter]] <br /> <br /> From the URL the important parameter is the value of the UserID query string (the value 23, above). We want to fuzz that. <br /> <br /> • Within the Fuzzing Tab, in the &quot;Request&quot; text area, highlight the above number 23 • Right-click and select &quot;Add&quot; <br /> <br /> In the &quot;Add a Fuzzer&quot; window that appears, select: <br /> <br /> • Category Name: &lt;code&gt;Base&lt;/code&gt; • Fuzzer Name: &lt;code&gt;Base10 (DEC)&lt;/code&gt; • Select &quot;Add Fuzzer&quot; in the bottom right <br /> <br /> This would have added a decimal (base 10 fuzzer) of length 2 onto the location. <br /> <br /> • You will see a row added within the &quot;Added Fuzzers Table&quot; of the Fuzzing panel. • Click &quot;Start&quot; &lt;code&gt;Ctrl+Enter&lt;/code&gt; <br /> <br /> This will transmit 100 requests to the domain in question, which in this case is assumed: www.myattackingdomain.com. The value being changed within each request will be: <br /> &lt;pre&gt;• GET /portal-location/UserInfo.aspx?UserID=00 HTTP/1.0<br /> • GET /portal-location/UserInfo.aspx?UserID=01 HTTP/1.0<br /> ...<br /> • GET /portal-location/UserInfo.aspx?UserID=98 HTTP/1.0<br /> • GET /portal-location/UserInfo.aspx?UserID=99 HTTP/1.0<br /> &lt;/pre&gt; <br /> Done. Let's proceed to graph the responses that we have obtained. Our objective is to understand which two-digit numbers from 00 to 99 correspond to valid user accounts. <br /> <br /> === Graphing Results ===<br /> <br /> • Within the &quot;Graphing&quot; tab, click &quot;Start&quot; &lt;code&gt;Ctrl+Enter&lt;/code&gt; <br /> <br /> A list of directories will appear on the left-hand side. If you scroll to the bottom of the list you should see the directory corresponding to your fuzzing session, in our case it was (175 2009-06-24 16-18-24) <br /> &lt;pre&gt;• Right-click on (175 2009-06-24 16-18-24)<br /> • Click &quot;Graph&quot;<br /> &lt;/pre&gt; <br /> This will generate the graphs in their respective tabs. The question now becomes which graph is of interest for our user enumeration exercise. <br /> <br /> By definition enumerating users against an ID value, or any other identifier involves being able to obtain a different response for an existing user to that of a user that is not have a corresponding ID value. <br /> <br /> Thus, from the metrics available, the one useful for enumerating users will be that of measuring the &quot;Hamming Distance&quot; between responses received. Based on the JBroFuzz documentation: <br /> <br /> '''Fuzzing Hamming Distance ''' <br /> &lt;pre&gt;A bar chart with the hamming distance of the characters in the response, <br /> relative to the first response received. Check each character of the first<br /> response received, against the character at the same position of the<br /> current response received. If they are not identical, increment the <br /> hamming distance.<br /> &lt;/pre&gt; <br /> As we can see the Fuzzing Hamming Distance (FHD) varies quite a bit from the definition of the normal hamming distance term, used in telecommunications. Still, they share a lot of similarities. <br /> <br /> As we can from the above, the first request is critical to calibrating our user enumeration exercise. It represents the value that all other Fuzzing Hamming Distances (FHD) will be measured and normalised towards. For the java-skilled audience, the algorithm is quite trivial, but offers spectacular results in distinguishing responses: <br /> &lt;pre&gt;in = new BufferedReader(new FileReader(f));<br /> 58 <br /> 59 int counter = 0;<br /> 60 int check = 0;<br /> 61 int c;<br /> 62 while (((c = in.read()) &amp;gt; 0) &amp;amp;&amp;amp; (counter &amp;lt; MAX_CHARS)) {<br /> 63 <br /> 64 // If we are passed &quot;--jbrofuzz--&amp;gt;\n&quot; in the file<br /> 65 if (check == END_SIGNATURE.length()) {<br /> 66 <br /> 67 firstSet.append((char) c);<br /> 68 <br /> 69 }<br /> 70 // Else find &quot;--jbrofuzz--&amp;gt;\n&quot; using a counter<br /> 71 else {<br /> 72 // Increment the counter for each success<br /> 73 if (c == END_SIGNATURE.charAt(check)) {<br /> 74 check++;<br /> 75 } else {<br /> 76 check = 0;<br /> 77 }<br /> 78 }<br /> 79 <br /> 80 counter++;<br /> 81 <br /> 82 }<br /> 83 in.close();<br /> &lt;/pre&gt; <br /> Ergo, the corresponding graph is depicted in the screenshot below. The peak graphs correspond to number that if you hover the mouse over will give you the enumeration ID of a valid user. <br /> <br /> [[Image:015-JBroFuzz-Tutorial.png|500px|Measuring Hamming Distance for User Enumeration]] <br /> <br /> == Eliminating False Positives: LDAP Injection ==<br /> <br /> Every now and then a tool (that does not produce false positives) will hit an application reporting back a huge variety of (hopefully not confirmed, but pending further investigation) injection findings. <br /> <br /> Due to the limited number of characters required in performing LDAP Injection, such issues will be high on that list. But let's refresh our memory a bit of how LDAP injection works:<br /> <br /> http://www.owasp.org/index.php/LDAP_injection<br /> <br /> So typically, during an automated scan, negating LDAP cn-type queries would be submitted and their responses noted. Example:<br /> <br /> &lt;pre&gt;<br /> GET /myfilelocation.jsp?lang=en&amp;city=user)(sn=*&amp;rid=97 HTTP/1.1<br /> ...<br /> &lt;/pre&gt;<br /> <br /> vs.<br /> <br /> &lt;pre&gt;<br /> GET /myfilelocation.jsp?lang=en&amp;city=user)!(sn=*&amp;rid=97 HTTP/1.1<br /> ...<br /> &lt;/pre&gt;<br /> <br /> or <br /> <br /> &lt;pre&gt;<br /> GET /myfilelocation.jsp?lang=en&amp;city=admin*)((|userpassword=*)&amp;rid=97 HTTP/1.1<br /> ...<br /> &lt;/pre&gt;<br /> <br /> As great as this check might be from an LDAP perspective, it has a high likelihood of generating false positives, due to the character sets being used. Ergo, a protection mechanism (silly worst-case blacklist present for example) would typically hunt down cross-site scripting and sql injection type of characters:<br /> <br /> &lt;pre&gt;<br /> &lt; &gt; ' etc.<br /> &lt;/pre&gt;<br /> <br /> Not considering =, *, or brackets as completely bad (he says). <br /> <br /> === What characters are allowed through? ===<br /> <br /> Enough of all that; we want to know what responses are allowed back and what's different about them for all characters being filtered through a black-list.<br /> <br /> Let's transform the above GET into the following and proceed to add a single fuzzer that tells us that:<br /> <br /> &lt;pre&gt;<br /> GET /myfilelocation.jsp?lang=en&amp;city=X&amp;rid=97 HTTP/1.1<br /> &lt;/pre&gt;<br /> <br /> Now in the position of the X character, proceed to add an ASCII 94 Alphabet Fuzzer (available in version 2.1 and above). This will check the responses for all characters which are printable ASCII, with the exception of space.<br /> <br /> In total there are 95 printable ASCII characters; minus the one present for space (yes, the one you hit all the time, every day) leaves 94. This fuzzer produces each of those values, in incrementing ASCII order.<br /> <br /> [[Image:020-JBroFuzz-Tutorial.png|500px|Measuring Size Length for Single Character ASCII 94 Fuzzing]] <br /> <br /> Based on the above graph, the following responses trigger a different response size. Thus the characters blocked by a black-list are:<br /> <br /> &lt;pre&gt;<br /> ! &quot; , &lt; &gt; @ [ \ ] ^ ` { | } ~<br /> &lt;/pre&gt;<br /> <br /> Interesting. Know any payloads that can evade those?<br /> :)<br /> <br /> == JBroFuzz Development Corner ==<br /> <br /> This section presents how to setup and use JBroFuzz as a fuzzing library. Also, it offers an insight in how to setup and compile your own version of JBroFuzz. As different people have different levels of expertise of the java programming language, eclipse, ant and subversion, some of the steps presented herein might be considered basic by advanced developers. <br /> <br /> === Setting up a JBroFuzz Development Environment ===<br /> <br /> This section guides you towards setting up a development environment for JBroFuzz. Despite the Operating System (O/S) being windows XP, a similar process can be followed in a number of other O/S. <br /> <br /> You will need to have installed: <br /> <br /> *Tortoise SVN (using TortoiseSVN-1.6.6.17493-win32-svn-1.6.6.msi) <br /> *Eclipse Java (using eclipse-java-galileo-SR1-win32.zip)<br /> <br /> Optionally, if you don't like building your application through eclipse you could also require to install Apache Ant. <br /> <br /> ==== Step 1: Obtain the source code ====<br /> <br /> JBroFuzz uses SubVersion with the repository being publicly available for download through anonymous access on sourceforge. There is a plan to move it the source to the OWASP Git repository, but until then, use the guidelines below. <br /> <br /> [[Image:010-JBroFuzz-Tutorial.png|Tortoise SVN Check out JBroFuzz Source Code]] <br /> <br /> Right click on the folder location where you want to download the source code and select: <br /> <br /> *SVN Checkout<br /> <br /> In the &quot;URL of repository&quot;, enter: <br /> &lt;pre&gt;https://jbrofuzz.svn.sourceforge.net/svnroot/jbrofuzz<br /> &lt;/pre&gt; <br /> In the &quot;Checkout directory&quot;, enter the folder location of your choice, in this case: <br /> &lt;pre&gt;C:\root\code\jbrofuzz<br /> &lt;/pre&gt; <br /> In the &quot;Checkout Depth&quot; select: <br /> <br /> *Fully recursive<br /> <br /> Untick &quot;Omit Externals&quot; (should be unticked by default) <br /> <br /> In the &quot;Revision&quot; select: <br /> <br /> *&quot;Head revision&quot;<br /> <br /> Select OK. <br /> <br /> This process, once complete will checkout the entirety of the JBroFuzz source code from the SVN repository on sourceforge. <br /> <br /> ==== Step 2: Configuring a JBroFuzz Project within Eclipse ====<br /> <br /> Having obtained the latest copy of the source code, the next step entails importing that source code within the Eclipse IDE. <br /> <br /> Within Eclipse, select: <br /> &lt;pre&gt;File -&amp;gt; New -&amp;gt; Other<br /> &lt;/pre&gt; <br /> From the &quot;New&quot; panel that appears, select: <br /> &lt;pre&gt;Java -&amp;gt; Java Project from Existig Ant Buildfile<br /> &lt;/pre&gt; <br /> [[Image:011-JBroFuzz-Tutorial.png|Import JBroFuzz Code into Eclipse from Ant File]] <br /> <br /> Select &quot;Next&quot;. <br /> <br /> In the next menu, under &quot;Ant buildfile&quot;, select &quot;Browse&quot;. <br /> <br /> Browse to the location where you have just (step 1) downloaded the source code and select the following file: <br /> <br /> *build.xml<br /> <br /> The build.xml file is an Ant build file that JBroFuzz uses. <br /> <br /> [[Image:012-JBroFuzz-Tutorial.png|Select the Ant File]] <br /> <br /> Selecting that file should have populated the &quot;Project name&quot; as jbrofuzz and also given you: <br /> <br /> &lt;br&gt; <br /> &lt;pre&gt;&quot;javac&quot; task found in target &quot;compile&quot;<br /> &lt;/pre&gt; <br /> MAKE SURE TO TICK: <br /> <br /> *&quot;Link to the buildfile in the filesystem&quot;<br /> <br /> Otherwise eclipse will try to replicate the source code within your workspace and that makes the process a tiny bit more complicated when it comes to actually building JBroFuzz. <br /> <br /> Click &quot;Finish&quot; <br /> <br /> You will see the item &quot;Building workspace (76%) on the bottom right hand side of Eclipse. Once that is complete, you should see the jbrofuzz project on the top left corner of the Package Explorer within Eclipse. <br /> <br /> ==== Step 3: Building JBroFuzz ====<br /> <br /> Within the Package Explorer, expand the jbrofuzz project and double-click on the build.xml file. <br /> <br /> Right click on the &quot;build [default]&quot; task within the &quot;Outline&quot; window (typically seen on the right hand side) and select: <br /> &lt;pre&gt;Run As -&amp;gt; 1. Ant Build [Alt+Shift+X, Q]<br /> &lt;/pre&gt; <br /> If the build has been successful, a JBroFuzz.jar file within the the /jar folder would have been created. Following the path conventions above that should be in: <br /> &lt;pre&gt;C:\root\code\jbrofuzz\jar\JBroFuzz.jar<br /> &lt;/pre&gt; <br /> [[Image:013-JBroFuzz-Tutorial.png|Building JBroFuzz within Eclipse]] <br /> <br /> === How to Use JBroFuzz as a Fuzzing Library ===<br /> <br /> Quite often what you need to do in terms of fuzzing, far exceeds the User Interface (UI) of JBroFuzz. For this reason, a set of core fuzzing APIs have been made available that can be used for more advanced fuzzing scenarios. <br /> <br /> The JBroFuzz.jar standalone archive (made available with every release) carries a core fuzzing library that holds a number of key classes. These are located under: <br /> &lt;pre&gt;org.owasp.jbrofuzz.core.*;<br /> -Database.java<br /> -Fuzzer.java<br /> -FuzzerBigInteger.java<br /> -NoSuchFuzzerException.java<br /> -Prototype.java<br /> &lt;/pre&gt; <br /> The class of importance is Fuzzer.java. If you are going to use recursive iterators of great length, there is also FuzzerBigInteger.java. The difference between the two is that Fuzzer.java uses the primitive java data type long (up to 16^16 values) while FuzzerBigInteger.java uses java BigInteger to perform the counting. Naturally, the class FuzzerBigInteger is slower and takes more memory than the Fuzzer class. <br /> <br /> Within JBroFuzz a Fuzzer is an instance of a java Iterator. This implies that values can be accessed by simply calling the &lt;code&gt;next()&lt;/code&gt; method once an object has been made available. Typically, a call to &lt;code&gt;hasNext()&lt;/code&gt; should also be performed prior to avoid an exception being thrown. <br /> <br /> A Fuzzer can be obtained from the factory method &lt;code&gt;createFuzzer(String, int);&lt;/code&gt; available for every instance of the fuzzing Database. Ergo: <br /> <br /> ==== A HelloFuzzer Example ====<br /> &lt;pre&gt;Database myDatabase = new Database();<br /> <br /> Fuzzer myFuzzer = myDatabase.createFuzzer(&quot;031-B16-HEX&quot;, 5);<br /> &lt;/pre&gt; <br /> So how do I use the API? Here is a simple HelloFuzzer (file called HelloFuzzer.java) example: <br /> &lt;pre&gt;import org.owasp.jbrofuzz.core.*;<br /> <br /> public class HelloFuzzer {<br /> <br /> public static void main(String[] args) {<br /> <br /> Database fuzzDB = new Database();<br /> <br /> try {<br /> for(Fuzzer f = fuzzDB.createFuzzer(&quot;031-B16-HEX&quot;, 4); f.hasNext();) {<br /> // Get the next payload value...<br /> System.out.println(&quot; The fuzzer payload is: &quot; + f.next());<br /> }<br /> } catch (NoSuchFuzzerException e) {<br /> System.out.println(&quot;Could not find fuzzer &quot; + e.getMessage());<br /> }<br /> <br /> }<br /> <br /> } // HelloFuzzer.java OWASP JBroFuzz Example 1<br /> &lt;/pre&gt; <br /> To compile the above use: <br /> &lt;pre&gt;javac -classpath &quot;.\jbrofuzz\jar\JBroFuzz.jar&quot; HelloFuzzer.java<br /> &lt;/pre&gt; <br /> This assumes that you are currently inside the directory where HelloFuzzer.java resides and that the JBroFuzz.jar is located two directories within your current location i.e. in jbrofuzz/jar. In order to run the above compiled HelloFuzzer class issue: <br /> &lt;pre&gt;java -cp &quot;.\jbrofuzz\jar\JBroFuzz.jar;.&quot; HelloFuzzer<br /> &lt;/pre&gt; <br /> Note: The above 2 commands have been crafted in a win32 environment. The process for compiling and running HelloFuzzer.java above is the same in *nix machines. Simply replace the backslash &quot;\&quot; with &quot;/&quot;. <br /> <br /> ==== Fuzzing Payload Definitions ====<br /> <br /> Within the JBroFuzz.jar file, there is a file called fuzzers.jbrf that carries all the fuzzer definitions that you see in the UI payloads tab of JBroFuzz. To view a latest copy of this file you can browse the SVN repository of JBroFuzz: <br /> &lt;pre&gt;http://jbrofuzz.svn.sourceforge.net/viewvc/jbrofuzz/tar/fuzzers.jbrf?view=log<br /> &lt;/pre&gt; <br /> A note here worth mentioning: Files ending in .jbrofuzz are session files saved by users while performing fuzzing operations. Files ending in .jbrf are JBroFuzz system files. Typical examples of .jbrf files are headers.jbrf, as well as fuzzers.jbrf. Both these use an internal proprietary format not to be confused with the .jbrofuzz file format. <br /> <br /> Fuzzers belong in categories (1 to many) and each fuzzer carries a set of payloads that define the alphabet of the fuzzer. <br /> <br /> Also, you have replacive and recursive fuzzers, zero fuzzers, etc. There are a number of different fuzzer categories. As an example of a fuzzer within the fuzzers.jbrf file, consider the hexadecimal fuzzer: <br /> &lt;pre&gt;Fuzzer Name: Base16 (HEX)<br /> Fuzzer Type: Recursive<br /> Fuzzer Id: 031-B16-HEX<br /> <br /> Total Number of Payloads: 16<br /> &lt;/pre&gt; <br /> Within the fuzzers.jbrf file this fuzzer is defined in plain-text format as follows: <br /> &lt;pre&gt;R:031-B16-HEX:Base16 (HEX):16<br /> &amp;gt; Number Systems | Base | Recursive Fuzzers<br /> 0<br /> 1<br /> 2<br /> 3<br /> 4<br /> 5<br /> 6<br /> 7<br /> 8<br /> 9<br /> a<br /> b<br /> c<br /> d<br /> e<br /> f<br /> &lt;/pre&gt; <br /> &lt;br&gt; There is very little preventing you from defining your own fuzzers within this file, by following the file format specified above. You can use the UI to see if they have been loaded successfully. <br /> <br /> Further to recursive and replacive fuzzers you also have zero fuzzers (i.e. a zero fuzzer of 1000 will just transmit 1000 requests as they are, without adding any payloads) double fuzzers, cross product fuzzers, etc. <br /> <br /> Notice the factory method Database.createFuzzer(&quot;031-B16-HEX&quot;, 4) yielding: &quot;I want a 4 digit recursive fuzzer (why because NUM-HEX is recursive in its definition, starts with R: instead of P:) of HEX digits.&quot; <br /> <br /> Thus the above scenario would iterate through all the digits from 0000 to ffff. I wouldn't recommend using the above scenario for such trivial fuzzing capabilities; simply presented as an example of the inner workings of JBroFuzz.jar <br /> <br /> ==== HelloFuzzer Refined ====<br /> <br /> A more detailed code breakdown of the above HelloFuzzer example can be found below: <br /> &lt;pre&gt;/**<br /> * JBroFuzz API Examples 01<br /> *<br /> * JBroFuzz - A stateless network protocol fuzzer for web applications.<br /> * <br /> * Copyright (C) 2007, 2008, 2009 subere@uncon.org<br /> *<br /> * This file is part of the JBroFuzz API examples on how to use the <br /> * fuzzer libraries included in JBroFuzz.jar.<br /> * <br /> * JBroFuzz is free software: you can redistribute it and/or modify<br /> * it under the terms of the GNU General Public License as published by<br /> * the Free Software Foundation, either version 3 of the License, or<br /> * (at your option) any later version.<br /> * <br /> * JBroFuzz is distributed in the hope that it will be useful,<br /> * but WITHOUT ANY WARRANTY; without even the implied warranty of<br /> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br /> * GNU General Public License for more details.<br /> * <br /> * You should have received a copy of the GNU General Public License<br /> * along with JBroFuzz. If not, see &amp;lt;http://www.gnu.org/licenses/&amp;gt;.<br /> * Alternatively, write to the Free Software Foundation, Inc., 51 <br /> * Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.<br /> * <br /> * Verbatim copying and distribution of this entire program file is <br /> * permitted in any medium without royalty provided this notice <br /> * is preserved. <br /> * <br /> */<br /> <br /> import org.owasp.jbrofuzz.core.NoSuchFuzzerException;<br /> import org.owasp.jbrofuzz.core.Database;<br /> import org.owasp.jbrofuzz.core.Fuzzer; <br /> <br /> /**<br /> * &amp;lt;p&amp;gt;In JBroFuzz a Fuzzer is a java Iterator.&amp;lt;/p&amp;gt;<br /> * <br /> * &amp;lt;p&amp;gt;In order to create a Fuzzer, use the factory method<br /> * Database.createFuzzer(String, int), passing as arguments<br /> * the Fuzzer ID and the specified length as a positive int.&amp;lt;/p&amp;gt;<br /> * <br /> * &amp;lt;p&amp;gt;Be careful to check that the fuzzer ID (labelled as f_ID)<br /> * is actually an existing ID from the Database of Fuzzers.&amp;lt;/p&amp;gt;<br /> * <br /> * &amp;lt;p&amp;gt;Expected Output:&amp;lt;/p&amp;gt;<br /> * &amp;lt;code&amp;gt;<br /> * The fuzzer payload is: 00000&amp;lt;br&amp;gt;<br /> * The fuzzer payload is: 00001&amp;lt;br&amp;gt;<br /> * ...&amp;lt;br&amp;gt;<br /> * (a total of 16^5 = 1048576 lines)&amp;lt;br&amp;gt;<br /> * ...&amp;lt;br&amp;gt;<br /> * The fuzzer payload is: ffffd&amp;lt;br&amp;gt;<br /> * The fuzzer payload is: ffffe&amp;lt;br&amp;gt;<br /> * The fuzzer payload is: fffff&amp;lt;br&amp;gt;<br /> * &amp;lt;/code&amp;gt;<br /> * <br /> * &amp;lt;p&amp;gt;For more information on the Database of Fuzzers, see the<br /> * HelloDatabase Class.&amp;lt;/p&amp;gt;<br /> * <br /> * @author subere@uncon.org<br /> * @version n/a<br /> */<br /> public class HelloFuzzer {<br /> <br /> /**<br /> * @param args<br /> */<br /> public static void main(String[] args) {<br /> <br /> // You have to construct an instance of the fuzzers database<br /> Database fuzzDB = new Database();<br /> // You have to supply a valid fuzzer ID<br /> String f_ID = &quot;031-B16-HEX&quot;;<br /> // You have to supply a (+)tive int<br /> int f_len = 5;<br /> <br /> try {<br /> <br /> for(Fuzzer f = fuzzDB.createFuzzer(f_ID, f_len); f.hasNext();) {<br /> <br /> // Get the next payload value...<br /> System.out.println(&quot; The fuzzer payload is: &quot; + f.next());<br /> <br /> }<br /> <br /> } catch (NoSuchFuzzerException e) {<br /> <br /> System.out.println(&quot;Could not find fuzzer &quot; + e.getMessage());<br /> <br /> }<br /> <br /> }<br /> <br /> }<br /> &lt;/pre&gt; <br /> ==== Hello Database of Fuzzers ====<br /> <br /> Having seen how to access a single Fuzzer through the createFuzzer() method available in the Database object. The next question that comes naturally is what are the Fuzzers that are available by default in JBroFuzz? <br /> <br /> To answer that, this example focuses more on the database component that we previously initialised, investigating the list of available methods that it offers. <br /> <br /> In JBroFuzz, all Fuzzers are stored in a Database object that you will be required to construct in order to access them. <br /> &lt;pre&gt;/**<br /> * JBroFuzz API Examples 02<br /> *<br /> * JBroFuzz - A stateless network protocol fuzzer for web applications.<br /> * <br /> * Copyright (C) 2007, 2008, 2009 subere@uncon.org<br /> *<br /> * This file is part of the JBroFuzz API examples on how to use the <br /> * fuzzer libraries included in JBroFuzz.jar.<br /> * <br /> * JBroFuzz is free software: you can redistribute it and/or modify<br /> * it under the terms of the GNU General Public License as published by<br /> * the Free Software Foundation, either version 3 of the License, or<br /> * (at your option) any later version.<br /> * <br /> * JBroFuzz is distributed in the hope that it will be useful,<br /> * but WITHOUT ANY WARRANTY; without even the implied warranty of<br /> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br /> * GNU General Public License for more details.<br /> * <br /> * You should have received a copy of the GNU General Public License<br /> * along with JBroFuzz. If not, see &amp;lt;http://www.gnu.org/licenses/&amp;gt;.<br /> * Alternatively, write to the Free Software Foundation, Inc., 51 <br /> * Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.<br /> * <br /> * Verbatim copying and distribution of this entire program file is <br /> * permitted in any medium without royalty provided this notice <br /> * is preserved. <br /> * <br /> */<br /> <br /> import org.owasp.jbrofuzz.core.NoSuchFuzzerException;<br /> import org.owasp.jbrofuzz.core.Database;<br /> import org.owasp.jbrofuzz.core.Fuzzer; <br /> <br /> /**<br /> * &amp;lt;p&amp;gt;In JBroFuzz all Fuzzers are stored in a Database<br /> * object that you will be required to construct in order<br /> * to access them.&amp;lt;/p&amp;gt;<br /> * <br /> * &amp;lt;p&amp;gt;Within the Database, each Fuzzer is a collection of <br /> * payloads, which carries a unique ID string value.&amp;lt;/p&amp;gt;<br /> * <br /> * &amp;lt;p&amp;gt;Example ID values are the output of this program:&amp;lt;/p&amp;gt;<br /> * &amp;lt;code&amp;gt;<br /> * The fuzzer ID is: 013-LDP-INJ&amp;lt;br&amp;gt;<br /> * The name of the fuzzer is: LDAP Injection&amp;lt;br&amp;gt;<br /> * The id of the fuzzer is: 013-LDP-INJ&amp;lt;br&amp;gt;<br /> * The of payloads it carries (it's alphabet) is: 20&amp;lt;br&amp;gt;<br /> * It has as 1st payload:&amp;lt;br&amp;gt;<br /> * |&amp;lt;br&amp;gt;<br /> * The fuzzer ID is: 018-XSS-4IE&amp;lt;br&amp;gt;<br /> * The name of the fuzzer is: XSS IE&amp;lt;br&amp;gt;<br /> * The id of the fuzzer is: 018-XSS-4IE&amp;lt;br&amp;gt;<br /> * The of payloads it carries (it's alphabet) is: 38&amp;lt;br&amp;gt;<br /> * It has as 1st payload:&amp;lt;br&amp;gt;<br /> * &amp;lt; img src=`x` onrerror= `&amp;nbsp;;; alert(1) ` /&amp;gt;&amp;lt;br&amp;gt;<br /> *<br /> * &amp;lt;/code&amp;gt;<br /> * <br /> * &amp;lt;p&amp;gt;Do not be confused between Prototypes and Fuzzers; <br /> * JBroFuzz uses Prototype objects to construct the Fuzzers<br /> * that get added into the Database upon initialisation.&amp;lt;/p&amp;gt;<br /> * <br /> * &amp;lt;p&amp;gt;As a result, the getter methods available within a Database<br /> * object can carry the name of getAllPrototypeIDs and <br /> * getAllFuzzerIDs interchangebly.&amp;lt;/p&amp;gt;<br /> * <br /> * @author subere@uncon.org<br /> * @version n/a<br /> */<br /> public class HelloDatabase {<br /> <br /> /**<br /> * @param args<br /> */<br /> public static void main(String[] args) {<br /> <br /> // You have to construct an instance of the fuzzers database<br /> Database fuzzDB = new Database();<br /> <br /> // Get a list of all the fuzzer IDs from the database<br /> String[] fuzzer_IDs = fuzzDB.getAllPrototypeIDs();<br /> <br /> System.out.println(&quot;The fuzzer IDs found are:&quot;);<br /> <br /> for(String fuzzerID&amp;nbsp;: fuzzer_IDs) {<br /> <br /> System.out.println(&quot;The fuzzer ID is: &quot; + fuzzerID);<br /> <br /> // We pass of length of 1, irrelevant if we are<br /> // just going to access the first payload<br /> // of the fuzzer<br /> Fuzzer fuzzer;<br /> try {<br /> <br /> fuzzer = fuzzDB.createFuzzer(fuzzerID, 1);<br /> // Normally you should check for fuzzer.hasNext() <br /> String payload = fuzzer.next();<br /> <br /> System.out.println(&quot;\tThe name of the fuzzer is:\t\t\t&quot; + fuzzer.getName() );<br /> System.out.println(&quot;\tThe id of the fuzzer is:\t\t\t&quot; + fuzzer.getId() );<br /> System.out.println(&quot;\tThe of payloads it carries (it's alphabet) is:\t&quot; + fuzzDB.getSize(fuzzerID));<br /> System.out.println(&quot;\tIt has as 1st payload:\n\t\t&quot; + payload );<br /> <br /> } catch (NoSuchFuzzerException e) {<br /> System.out.println(&quot;Could not find the specified fuzzer!&quot;);<br /> System.out.println(&quot;Going to print all the fuzzer IDs I know:&quot;);<br /> // old vs new for loop&amp;nbsp;:)<br /> // in case of an error, print just the <br /> // fuzzer IDs, accessed from the DB<br /> for(int j = 0; j &amp;lt; fuzzer_IDs.length; j++) {<br /> System.out.println(&quot;The fuzzer ID is: &quot; + fuzzer_IDs[j]);<br /> }<br /> <br /> }<br /> <br /> }<br /> <br /> }<br /> <br /> }<br /> &lt;/pre&gt; <br /> ==== Methods available within the Fuzzer Class ====<br /> <br /> A final example of this section, involves seeing the usage of all the method calls available in the Fuzzer.java class <br /> &lt;pre&gt;/**<br /> * JBroFuzz API Examples 03<br /> *<br /> * JBroFuzz - A stateless network protocol fuzzer for web applications.<br /> * <br /> * Copyright (C) 2007, 2008, 2009 subere@uncon.org<br /> *<br /> * This file is part of the JBroFuzz API examples on how to use the <br /> * fuzzer libraries included in JBroFuzz.jar.<br /> * <br /> * JBroFuzz is free software: you can redistribute it and/or modify<br /> * it under the terms of the GNU General Public License as published by<br /> * the Free Software Foundation, either version 3 of the License, or<br /> * (at your option) any later version.<br /> * <br /> * JBroFuzz is distributed in the hope that it will be useful,<br /> * but WITHOUT ANY WARRANTY; without even the implied warranty of<br /> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br /> * GNU General Public License for more details.<br /> * <br /> * You should have received a copy of the GNU General Public License<br /> * along with JBroFuzz. If not, see &amp;lt;http://www.gnu.org/licenses/&amp;gt;.<br /> * Alternatively, write to the Free Software Foundation, Inc., 51 <br /> * Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.<br /> * <br /> * Verbatim copying and distribution of this entire program file is <br /> * permitted in any medium without royalty provided this notice <br /> * is preserved. <br /> * <br /> */<br /> <br /> import org.owasp.jbrofuzz.core.NoSuchFuzzerException;<br /> import org.owasp.jbrofuzz.core.Database;<br /> import org.owasp.jbrofuzz.core.Fuzzer; <br /> <br /> /**<br /> * &amp;lt;p&amp;gt;Example iterating through all the methods available<br /> * in the Fuzzer Object and their respective outputs.&amp;lt;/p&amp;gt;<br /> *<br /> * @author subere@uncon.org<br /> * @version n/a<br /> */<br /> public class IndigoFuzzerTests {<br /> <br /> /**<br /> * @param args<br /> */<br /> public static void main(String[] args) {<br /> <br /> // You have to construct an instance of the fuzzers database<br /> Database fuzzDB = new Database();<br /> // You have to supply a valid fuzzer ID<br /> String f_ID = &quot;033-B08-OCT&quot;;<br /> // You have to supply a (+)tive int<br /> int f_len = 5;<br /> <br /> try {<br /> <br /> Fuzzer f = fuzzDB.createFuzzer(f_ID, f_len);<br /> <br /> while(f.hasNext()) {<br /> <br /> // Could do this via reflection, but..<br /> f.next();<br /> // System.out.println(&quot; The fuzzer payload is: &quot; + f.next());<br /> System.out.println(&quot; The maximum value is: &quot; + f.getMaximumValue());<br /> <br /> System.out.println(&quot; The current value is: &quot; + f.getCurrectValue());<br /> <br /> <br /> <br /> }<br /> <br /> <br /> } catch (NoSuchFuzzerException e) {<br /> <br /> System.out.println(&quot;Could not find fuzzer &quot; + e.getMessage());<br /> <br /> }<br /> <br /> }<br /> <br /> }<br /> &lt;/pre&gt; <br /> === Advanced Fuzzing with the JBroFuzz Library ===<br /> <br /> This section covers more advanced APIs that are available under the '''org.owasp.jbrofuzz.core package'''. It should be noted that some of these classes and their corresponding functionality are not used by the JBroFuzz program application. Instead, they are made available for incorporation into other java code that you have perhaps written that requires more specialized type of fuzzing. <br /> <br /> ==== Fuzzing Really Long Values with Big Integer ====<br /> <br /> As stated previously, within JBroFuzz a Fuzzer is a java Iterator. This implies that while fuzzing, we typically keep track of a counter representing the value that we are currently on. Consider the example of HelloFuzzer.java, above: <br /> &lt;pre&gt;import org.owasp.jbrofuzz.core.*;<br /> <br /> public class HelloFuzzer {<br /> <br /> public static void main(String[] args) {<br /> <br /> Database fuzzDB = new Database();<br /> <br /> try {<br /> for(Fuzzer f = fuzzDB.createFuzzer(&quot;031-B16-HEX&quot;, 4); f.hasNext();) {<br /> // Get the next payload value...<br /> System.out.println(&quot; The fuzzer payload is: &quot; + f.next());<br /> }<br /> } catch (NoSuchFuzzerException e) {<br /> System.out.println(&quot;Could not find fuzzer &quot; + e.getMessage());<br /> }<br /> <br /> }<br /> <br /> } // HelloFuzzer.java OWASP JBroFuzz Example 1<br /> &lt;/pre&gt; <br /> If we compile this program: <br /> &lt;pre&gt;javac -classpath &quot;.\jbrofuzz\jar\JBroFuzz.jar&quot; HelloFuzzer.java<br /> &lt;/pre&gt; <br /> and run it: <br /> &lt;pre&gt;java -cp &quot;.\jbrofuzz\jar\JBroFuzz.jar;.&quot; HelloFuzzer<br /> &lt;/pre&gt; <br /> We are going to see output similar to: <br /> &lt;pre&gt; The fuzzer payload is: 0000<br /> ... (output omitted)<br /> The fuzzer payload is: fffd<br /> The fuzzer payload is: fffe<br /> The fuzzer payload is: ffff<br /> &lt;/pre&gt; <br /> Now what if we want a hexadecimal fuzzer of length not 4, but, say, 24. Let's try compile and run the above program with a length of 24. Changing the line to: <br /> &lt;pre&gt; for(Fuzzer f = fuzzDB.createFuzzer(&quot;031-B16-HEX&quot;, 24); f.hasNext();) {<br /> &lt;/pre&gt; <br /> Running this modified version of HelloFuzzer.java, yields: <br /> &lt;pre&gt;&amp;gt;javac -classpath &quot;.\jbrofuzz\jar\JBroFuzz.jar;.&quot; HelloFuzzer.java<br /> <br /> &amp;gt;java -classpath &quot;.\jbrofuzz\jar\JBroFuzz.jar;.&quot; HelloFuzzer<br /> <br /> &amp;gt;<br /> &lt;/pre&gt; <br /> Nothing! What is actually happening is JBroFuzz is figuring out that the specified length of the Fuzzer we are about to create is far greater than that of the long java data type. As a result, the Fuzzer is not even entering the iteration mode that is typically expected with methods next() and hasNext(). <br /> <br /> That's all great, but we still want a hexadecimal fuzzer, 24 digits long going from: <br /> &lt;pre&gt;000000000000000000000000<br /> ...to...<br /> ffffffffffffffffffffffff<br /> &lt;/pre&gt; <br /> For this JBroFuzz offers another type of Fuzzer class, that of FuzzerBigInteger. Let's modify the critical line within the original HelloFuzzer.java program that we had: <br /> &lt;pre&gt; for(FuzzerBigInteger f = fuzzDB.createFuzzerBigInteger(&quot;031-B16-HEX&quot;, 24); f.hasNext();) {<br /> &lt;/pre&gt; <br /> With the entire program becoming: <br /> &lt;pre&gt;import org.owasp.jbrofuzz.core.*;<br /> <br /> public class HelloFuzzer {<br /> <br /> public static void main(String[] args) {<br /> <br /> Database fuzzDB = new Database();<br /> <br /> try {<br /> for(FuzzerBigInteger f = fuzzDB.createFuzzerBigInteger(&quot;031-B16-HEX&quot;, 24); f.hasNext();) {<br /> // Get the next payload value...<br /> System.out.println(&quot; The fuzzer payload is: &quot; + f.next());<br /> }<br /> } catch (NoSuchFuzzerException e) {<br /> System.out.println(&quot;Could not find fuzzer &quot; + e.getMessage());<br /> }<br /> <br /> }<br /> <br /> } // HelloFuzzer.java OWASP JBroFuzz Example 1<br /> &lt;/pre&gt; <br /> Compiling and running this program yields: <br /> &lt;pre&gt; The fuzzer payload is: 000000000000000000000000<br /> The fuzzer payload is: 000000000000000000000001<br /> ... (output omitted)<br /> The fuzzer payload is: 00000000000000000001a982<br /> ... (output omitted)<br /> The fuzzer payload is: 00000000000000000001a982<br /> The fuzzer payload is: ffffffffffffffffffffffff<br /> &lt;/pre&gt; <br /> There are limitations to this class, as governed by the BigInteger class itself. Further information can be found at: <br /> &lt;pre&gt;http://java.sun.com/j2se/1.5.0/docs/api/java/math/BigInteger.html<br /> &lt;/pre&gt; <br /> Still, on a virtual windows xp machine with 256Mb of RAM the above code had no problem running to completion. It took some time though.. Characteristics of the windows machine while this iteration was ongoing: The CPU was being utilised at 100% and memory usage was constant at 212 Mb. Overall, a clean sheet for FuzzerBigInteger.java. <br /> <br /> ==== Using the Power Fuzzer API ====<br /> <br /> With web applications, it is often that you find yourself re-using part of, or the entirety of a fuzzing payload in more than one location, as part of the GET, POST, or any other type of request you submit. <br /> <br /> For this reason, JBroFuzz offers the PowerFuzzer class: A type of iterator for which you can specify how many copies of the payload you require in each request. <br /> <br /> Let's consider the following trivial scenario. You are in need of all hexadecimal values, which are 4-digits long (i.e. 0000 to FFFF) and you are in need of these 5 times for each request. <br /> <br /> This scenario is trivial, because typically you can assign the fuzzing payload (i.e. the value you get back from Fuzzer.next() ) to a String variable and re-use it as many times as you see fit. <br /> &lt;pre&gt; Database fuzzDB = new Database();<br /> <br /> String fuzzerID = &quot;031-B16-HEX&quot;;<br /> int length = 4;<br /> ....<br /> for(Fuzzer f = fuzzDB.createFuzzer(fuzzerID, length); f.hasNext();) {<br /> String payload = f.next();<br /> ....<br /> }<br /> &lt;/pre&gt; <br /> Using the PowerFuzzer.class, the following HelloPowerFuzzer.java program can be created: <br /> &lt;pre&gt;import org.owasp.jbrofuzz.core.*;<br /> <br /> public class HelloPowerFuzzer {<br /> <br /> public static void main(String[] args) {<br /> <br /> Database fuzzDB = new Database();<br /> <br /> String fuzzerID = &quot;031-B16-HEX&quot;;<br /> int length = 4;<br /> int power = 5;<br /> <br /> try {<br /> for(PowerFuzzer f = fuzzDB.createPowerFuzzer(fuzzerID, length, power); f.hasNext();) {<br /> // Get the next payload in an array of length[power]<br /> String [] identicalElements = f.nextPower();<br /> <br /> // f.getPower() == identicalElements.length, always<br /> System.out.print(&quot; I have &quot; + f.getPower() + &quot; elements: &quot;);<br /> <br /> for(String elem&amp;nbsp;: identicalElements) {<br /> <br /> System.out.print(elem + &quot; &quot;);<br /> }<br /> System.out.println(&quot;&quot;);<br /> <br /> }<br /> } catch (NoSuchFuzzerException e) {<br /> System.out.println(&quot;Could not find fuzzer &quot; + e.getMessage());<br /> }<br /> <br /> }<br /> <br /> } // HelloPowerFuzzer.java OWASP JBroFuzz Power Fuzzer Example<br /> <br /> &lt;/pre&gt; <br /> This program would output the following; no rocket science here: <br /> &lt;pre&gt;....<br /> I have 5 elements: 4817 4817 4817 4817 4817<br /> I have 5 elements: 4818 4818 4818 4818 4818<br /> I have 5 elements: 4819 4819 4819 4819 4819<br /> I have 5 elements: 481a 481a 481a 481a 481a<br /> I have 5 elements: 481b 481b 481b 481b 481b<br /> I have 5 elements: 481c 481c 481c 481c 481c<br /> I have 5 elements: 481d 481d 481d 481d 481d<br /> I have 5 elements: 481e 481e 481e 481e 481e<br /> I have 5 elements: 481f 481f 481f 481f 481f<br /> I have 5 elements: 4820 4820 4820 4820 4820<br /> I have 5 elements: 4821 4821 4821 4821 4821<br /> I have 5 elements: 4822 4822 4822 4822 4822<br /> I have 5 elements: 4823 4823 4823 4823 4823<br /> I have 5 elements: 4824 4824 4824 4824 4824<br /> I have 5 elements: 4825 4825 4825 4825 4825<br /> I have 5 elements: 4826 4826 4826 4826 4826<br /> ....<br /> &lt;/pre&gt; <br /> Now imagine you need to change the number of elements you obtain back every time. For every second request, you need to obtain back two identical payloads, for every third request, you need to obtain back three payloads and for every fourth request, you need to obtain back four payloads. <br /> <br /> The PowerFuzzer class, with the corresponding method '''setPower(int)''' allows you to set how many identical elements you obtain back, without having to worry about the length argument. Below is a class that solves the above scenario: <br /> &lt;pre&gt;import org.owasp.jbrofuzz.core.*;<br /> <br /> public class HelloPowerFuzzer {<br /> <br /> public static void main(String[] args) {<br /> <br /> Database fuzzDB = new Database();<br /> <br /> String fuzzerID = &quot;031-B16-HEX&quot;;<br /> int length = 4;<br /> int power = 5;<br /> <br /> try {<br /> for(PowerFuzzer f = fuzzDB.createPowerFuzzer(fuzzerID, length, power); f.hasNext();) {<br /> <br /> int currentValue = (int) f.getCurrentValue(); <br /> currentValue&amp;nbsp;%= 4;<br /> switch (currentValue) {<br /> case 0: f.setPower(1); break;<br /> case 1: f.setPower(2); break;<br /> case 2: f.setPower(3); break;<br /> default: f.setPower(4); break;<br /> }<br /> <br /> // Get the next payload in an array of length[power]<br /> String [] identicalElements = f.nextPower();<br /> <br /> // f.getPower() == identicalElements.length, always<br /> System.out.print(&quot; I have &quot; + f.getPower() + &quot; elements: &quot;);<br /> // System.out.println(currentValue);<br /> <br /> for(String elem&amp;nbsp;: identicalElements) {<br /> <br /> System.out.print(elem + &quot; &quot;);<br /> }<br /> System.out.println(&quot;&quot;);<br /> <br /> }<br /> } catch (NoSuchFuzzerException e) {<br /> System.out.println(&quot;Could not find fuzzer &quot; + e.getMessage());<br /> }<br /> <br /> }<br /> <br /> } // HelloPowerFuzzer.java<br /> <br /> &lt;/pre&gt; <br /> This class has as output: <br /> &lt;pre&gt; ....<br /> I have 1 elements: 22a8<br /> I have 2 elements: 22a9 22a9<br /> I have 3 elements: 22aa 22aa 22aa<br /> I have 4 elements: 22ab 22ab 22ab 22ab<br /> I have 1 elements: 22ac<br /> I have 2 elements: 22ad 22ad<br /> I have 3 elements: 22ae 22ae 22ae<br /> I have 4 elements: 22af 22af 22af 22af<br /> I have 1 elements: 22b0<br /> I have 2 elements: 22b1 22b1<br /> I have 3 elements: 22b2 22b2 22b2<br /> I have 4 elements: 22b3 22b3 22b3 22b3<br /> I have 1 elements: 22b4<br /> I have 2 elements: 22b5 22b5<br /> I have 3 elements: 22b6 22b6 22b6<br /> I have 4 elements: 22b7 22b7 22b7 22b7<br /> I have 1 elements: 22b8<br /> I have 2 elements: 22b9 22b9<br /> ....<br /> &lt;/pre&gt; <br /> Naturally, the algorithm of the number of elements required can vary based on any number of parameters. The PowerFuzzer class gives you a quick way to control the number of identical payloads you obtain back, without having to worry about creating a data type to store them in. <br /> <br /> ==== Using the Double Fuzzer API ====<br /> <br /> In some cases of fuzzing web applications, a requirement to fuzz two (or more) locations part of the request being submitted to the web server becomes apparent. <br /> <br /> The DoubleFuzzer class allows you to create a fuzzer based on two prototype definitions. Similarly to instantiating a Fuzzer through a prototype and a given length, with a DoubleFuzzer, we pass two prototype definitions and two lengths. The corresponding method call available within the '''Database''' class of org.owasp.jbrofuzz.core is: <br /> &lt;pre&gt;public DoubleFuzzer createDoubleFuzzer(String id1, int length1, <br /> String id2, int length2) throws NoSuchFuzzerException {<br /> &lt;/pre&gt; <br /> Let's cross-breed some fuzzers, see what results we get back during an iteration. <br /> <br /> The first example below, uses two hexadecimal fuzzers of different lengths, as specified by the variables: <br /> &lt;pre&gt;String fuzzID1 = &quot;031-B16-HEX&quot;;<br /> String fuzzID2 = &quot;031-B16-HEX&quot;;<br /> <br /> int length1 = 4;<br /> int length2 = 2;<br /> &lt;/pre&gt; <br /> As the double fuzzer iteration is taking place, the second fuzzer, defined by the fuzzID2 &amp;amp; length2 loops, starting from 00 and going all the way up to FF. An example output is: <br /> &lt;pre&gt; I have 2 elements: fefb fb<br /> I have 2 elements: fefc fc<br /> I have 2 elements: fefd fd<br /> I have 2 elements: fefe fe<br /> I have 2 elements: feff ff<br /> I have 2 elements: ff00 00<br /> I have 2 elements: ff01 01<br /> I have 2 elements: ff02 02<br /> I have 2 elements: ff03 03<br /> &lt;/pre&gt; <br /> The complete code listing of HelloDoubleFuzzer.java is: <br /> &lt;pre&gt;import org.owasp.jbrofuzz.core.*;<br /> <br /> public class HelloDoubleFuzzer {<br /> <br /> public static void main(String[] args) {<br /> <br /> Database fuzzDB = new Database();<br /> <br /> String fuzzID1 = &quot;031-B16-HEX&quot;;<br /> String fuzzID2 = &quot;031-B16-HEX&quot;;<br /> <br /> int length1 = 4;<br /> int length2 = 2;<br /> <br /> try {<br /> DoubleFuzzer f = fuzzDB.createDoubleFuzzer(fuzzID1, length1, fuzzID2, length2);<br /> <br /> while( f.hasNext() ) {<br /> // Get the next payload in an array of length[power]<br /> String [] payloads = f.next();<br /> <br /> // f.getPower() == identicalElements.length, always<br /> System.out.print(&quot; I have &quot; + f.getPower() + &quot; elements: &quot;);<br /> // System.out.println(currentValue);<br /> <br /> for(String elem&amp;nbsp;: payloads) {<br /> <br /> System.out.print(elem + &quot; &quot;);<br /> }<br /> System.out.println(&quot;&quot;);<br /> <br /> }<br /> } catch (NoSuchFuzzerException e) {<br /> System.out.println(&quot;Could not find fuzzer &quot; + e.getMessage());<br /> }<br /> <br /> }<br /> <br /> } // HelloDoubleFuzzer.java<br /> &lt;/pre&gt; <br /> That's simple enough; now let's cross-breed something a bit more exotic: Imagine a 3-digit octal ID value [000 - 777] being submitted inline with, say, a parameter that we want to test for Cross-Site Scripting (XSS). Let's adjust the program above with the corresponding fuzzer IDs of these fuzzers. Remember all the IDs of all the fuzzers can be found in the fuzzers.jbrf file within JBroFuzz.jar: <br /> &lt;pre&gt;import org.owasp.jbrofuzz.core.*;<br /> <br /> public class HelloDoubleFuzzer {<br /> <br /> public static void main(String[] args) {<br /> <br /> Database fuzzDB = new Database();<br /> <br /> String fuzzID1 = &quot;033-B08-OCT&quot;;<br /> String fuzzID2 = &quot;019-XSS-GEK&quot;;<br /> <br /> int length1 = 3;<br /> int length2 = 1;<br /> <br /> try {<br /> DoubleFuzzer f = fuzzDB.createDoubleFuzzer(fuzzID1, length1, fuzzID2, length2);<br /> <br /> while( f.hasNext() ) {<br /> // Get the next payload in an array of length[power]<br /> String [] payloads = f.next();<br /> <br /> // f.getPower() == identicalElements.length, always<br /> System.out.print(&quot; I have &quot; + f.getPower() + &quot; elements: &quot;);<br /> // System.out.println(currentValue);<br /> <br /> for(String elem&amp;nbsp;: payloads) {<br /> <br /> System.out.print(elem + &quot; &quot;);<br /> }<br /> System.out.println(&quot;&quot;);<br /> <br /> }<br /> } catch (NoSuchFuzzerException e) {<br /> System.out.println(&quot;Could not find fuzzer &quot; + e.getMessage());<br /> }<br /> <br /> }<br /> <br /> } // HelloDoubleFuzzer.java<br /> &lt;/pre&gt; <br /> The output from this program is: <br /> &lt;pre&gt; I have 2 elements: 000 (1?(1?{a:1?&quot;&quot;[1?&quot;ev\a\l&quot;:0](1?&quot;\a\lert&quot;:0):0}:0).a:0)[1?&quot;\c\a\l\l&quot;:0](content,1?&quot;x\s\s&quot;:0)<br /> I have 2 elements: 001 &amp;lt;STYLE TYPE=&quot;text/javascript&quot;&amp;gt;alert('XSS');&amp;lt;/STYLE&amp;gt;<br /> I have 2 elements: 002 &amp;lt;SCRIPT SRC=http://ha.ckers.org/xss.js<br /> I have 2 elements: 003 &amp;lt;A HREF=&quot;http://google:ha.ckers.org&quot;&amp;gt;XSS&amp;lt;/A&amp;gt;<br /> I have 2 elements: 004 &amp;lt;A HREF=&quot;http://ha.ckers.org@google&quot;&amp;gt;XSS&amp;lt;/A&amp;gt;<br /> I have 2 elements: 005 &amp;lt;A HREF=&quot;//google&quot;&amp;gt;XSS&amp;lt;/A&amp;gt;<br /> ....<br /> ...<br /> ..<br /> .<br /> ..<br /> ...<br /> ....<br /> I have 2 elements: 774 &amp;lt;SCRIPT SRC=http://ha.ckers.org/xss.js<br /> I have 2 elements: 775 &amp;lt;A HREF=&quot;http://google:ha.ckers.org&quot;&amp;gt;XSS&amp;lt;/A&amp;gt;<br /> I have 2 elements: 776 &amp;lt;A HREF=&quot;http://ha.ckers.org@google&quot;&amp;gt;XSS&amp;lt;/A&amp;gt;<br /> I have 2 elements: 777 &amp;lt;A HREF=&quot;//google&quot;&amp;gt;XSS&amp;lt;/A&amp;gt;<br /> &lt;/pre&gt; <br /> With the list stopping iterating at the last element of the greatest of the two fuzzers. <br /> <br /> ==== Using the Cross Product Fuzzer API ====<br /> <br /> A final case of a special Double Fuzzer is the the Cross Product Fuzzer of the payloads of two fuzzers. This type of fuzzing is virtually encountered in username/password login form on the Internet. Let's work on this by example. <br /> <br /> Consider your home network router. You recall changing the default password to one of the typical password values that you use. Also, you are not 100% certain about the username for the router either, it is one of the typical admin, user, administrator, root, yoda type values, but you cannot recall which one. Needless to say, you don't know what the username, or password actually is. <br /> <br /> So in a mini brute-forcing attack scenario, you have the following list of usernames, out of which one is valid: <br /> &lt;pre&gt;admin<br /> administrator<br /> Administrator<br /> root<br /> adminUser<br /> &lt;/pre&gt; <br /> Also you know that the password is one of the following (Top 10 Threadwatch 2007 passwords): <br /> &lt;pre&gt;password<br /> 123456<br /> qwerty<br /> abc123<br /> letmein<br /> monkey<br /> myspace1<br /> password1<br /> blink182<br /> &lt;/pre&gt; <br /> The set that contains every possible combination of the two sets is the Cross Product of the list of usernames, times the list of passwords. So manually, (as most people do while locking themselves out) you would try, popular combinations of the above, starting with: <br /> &lt;pre&gt;admin password<br /> admin 123456<br /> admin qwerty<br /> ....<br /> admin blink182<br /> administrator password<br /> administrator 123456<br /> administrator qwerty<br /> ....<br /> adminUser password1<br /> adminUser blink182<br /> &lt;/pre&gt; <br /> Thus the total number of attempts would be (number of usernames) x (number of passwords). No rocket science here. <br /> <br /> JBroFuzz introduces the CrossProductFuzzer class capable of iterating through the cross product of two fuzzers. Let's put it into code; the following program provides a list of all 2-digit octal numbers with every 2-digit binary number. A total of (8 x 8) x (2 x 2) = 256 values. <br /> &lt;pre&gt;import org.owasp.jbrofuzz.core.*;<br /> <br /> public class HelloCrossFuzzer {<br /> <br /> public static void main(String[] args) {<br /> <br /> Database fuzzDB = new Database();<br /> <br /> String fuzzID1 = &quot;033-B08-OCT&quot;;<br /> String fuzzID2 = &quot;034-B02-BIN&quot;;<br /> <br /> int length1 = 2;<br /> int length2 = 2;<br /> <br /> try {<br /> CrossProductFuzzer f = fuzzDB.createCrossFuzzer(fuzzID1, length1, fuzzID2, length2);<br /> <br /> while( f.hasNext() ) {<br /> // Get the next payload in an array of length[power]<br /> String [] payloads = f.next();<br /> <br /> // f.getPower() == identicalElements.length, always<br /> System.out.print(&quot; I have &quot; + f.getPower() + &quot; elements: &quot;);<br /> // System.out.println(currentValue);<br /> <br /> for(String elem&amp;nbsp;: payloads) {<br /> <br /> System.out.print(elem + &quot; &quot;);<br /> }<br /> System.out.println(&quot;&quot;);<br /> <br /> }<br /> } catch (NoSuchFuzzerException e) {<br /> System.out.println(&quot;Could not find fuzzer &quot; + e.getMessage());<br /> }<br /> <br /> }<br /> <br /> } // HelloCrossFuzzer.java<br /> &lt;/pre&gt; <br /> This program has as output: <br /> &lt;pre&gt; I have 2 elements: 00 00<br /> ...<br /> ..<br /> .<br /> ..<br /> ...<br /> I have 2 elements: 74 00<br /> I have 2 elements: 74 01<br /> I have 2 elements: 74 10<br /> I have 2 elements: 74 11<br /> I have 2 elements: 75 00<br /> I have 2 elements: 75 01<br /> I have 2 elements: 75 10<br /> I have 2 elements: 75 11<br /> I have 2 elements: 76 00<br /> I have 2 elements: 76 01<br /> I have 2 elements: 76 10<br /> I have 2 elements: 76 11<br /> I have 2 elements: 77 00<br /> I have 2 elements: 77 01<br /> I have 2 elements: 77 10<br /> I have 2 elements: 77 11<br /> &lt;/pre&gt; <br /> You can substitute any list of fuzzer ID to the IDs you use in this program. <br /> <br /> '''Remember!''' The total number of payloads must not exceed that of the the maximum value of the long primitive java data type ''Long.MAX_VALUE'' which is 2^63 - 1. If you are in need of more than that payloads, you would have to use the big integer implementation of the Fuzzer class, namely: FuzzerBigInteger.java. <br /> <br /> == Graphing with JBroFuzz ==<br /> <br /> Once a fuzzing session has completed, JBroFuzz offers the ability to generate a number of graphs, using various metrics. This section investigates how to further the graphing functionality available with the application. <br /> <br /> === Customizing the logo on each Graph ===<br /> <br /> As of version 2.0, all image icons within JBroFuzz are located within the /icons directory of the application. The particular transparent image file displayed on top right part of the graphs is named: <br /> &lt;pre&gt;/icons/owasp-med.png<br /> &lt;/pre&gt; <br /> This file is a 64 x 64 PNG image file. You can replace it with your own file, as follows: <br /> &lt;pre&gt;&amp;gt;ls -l JBroFuzz.jar<br /> -rw-rw-rw- 1 user group 4033612 Feb 15 12:33 JBroFuzz.jar<br /> <br /> &amp;gt;unzip -oq JBroFuzz.jar<br /> &amp;gt;cd icons<br /> &amp;gt;mv owasp-med.png file64x64-file.png<br /> &amp;gt;cd ..<br /> &amp;gt;zip -r JBroFuzz.zip *<br /> &amp;gt;mv JBroFuzz.zip JBroFuzz.jar<br /> &lt;/pre&gt; <br /> This enables you to have your own (company logo) on JBroFuzz graphs. Further to this, a number of other customization options are available, by right clicking on each of the graph generated. <br /> <br /> [[Category:OWASP_JBroFuzz]]</div>

Jorge Correa https://wiki.owasp.org/index.php?title=OWASP_JBroFuzz_Tutorial&diff=83956 2010-05-26T16:47:28Z

<p>Jorge Correa: /* Introduction */</p> <hr /> <div>&lt;br&gt; <br /> <br /> == Introduction ==<br /> <br /> ''“Si you can’t fuzz with JBroFuzz, you probably do not want to fuzz!”'' <br /> &lt;div align=&quot;right&quot;&gt;Old JBroFuzz Motto &lt;/div&gt; <br /> &lt;br&gt; The art of teaching, Mark Van Doren said, is the art of assisting discovery. Fuzzing is a representative discipline towards assisting the discovery of security vulnerabilities, that is just beginning to come of age. Over the last two years, through continuous development, JBroFuzz has attempted to expose the intrinsic beauty of the subject: Constantly submit a vast amount of payloads to a service, device or prompt, waiting for the one response that makes all the difference. This is the mentality that JBroFuzz embraces and attempts to offer back to security professionals. <br /> <br /> Fuzzing as a concept goes beyond a conventional work flow or a standard methodology. I would argue that to know how to fuzz well, is to master a new language. Thus, similar to the process of learning a programming (or foreign) language, there are three things you must master: <br /> <br /> • Grammar: How fuzzing as a process is structured&lt;br&gt; • Vocabulary: How to name fuzzing concepts you want to use&lt;br&gt; • Usage: Ways of achieving everyday effective results with fuzzing&lt;br&gt; <br /> <br /> [[Image:001-JBroFuzz-Tutorial.jpg|right|300px|JBroFuzz Splash Screen]]From the pre-existing information available for JBroFuzz, this tutorial focuses on usage: How to best put a fuzzing tool to good use, either via the UI, or using APIs that ''JBroFuzz.jar'' is constituted of. As a result, this document has a small requirement as a caveat; you need to have a beginner level understanding of the Java programming language in order to understand some sections. <br /> <br /> There are a number of working examples described here within, which '''grep''' for statements such as “''&lt;nowiki&gt;public static void main(String[] args)&lt;/nowiki&gt;''”. The majority of the content relates to reviewing these examples and putting the Java syntax into a fuzzing perspective. <br /> <br /> To summarise, this tutorial focuses on customary and effective usage of fuzzing through the JBroFuzz Java APIs and the respective UI. It is targeting (without attacking them) web applications. Without further redo, let’s get fuzzing!<br /> <br /> == JBroFuzz Basic Functionality ==<br /> <br /> This section carries a number of basic fuzzing examples to get you started with JBroFuzz. Overall, even though the actions performed to not produce any amazing fuzzing results, it serves as a starting point in understanding how to perform particular fuzzing operations on web applications. <br /> <br /> === 'Hello Google!' (forget 'Hello World') ===<br /> <br /> As the traditional first program that you learn when indulging in a new programming language, 'Hello World!' represents the norm for understanding the basic output operations and syntax (let alone compiler and execution behaviour) of the language in question. <br /> <br /> As with most web application security related tools, when I am given the responsibility to run them, often in order to understand how they work, I would first craft a legitimate, single request to a trusted (to be up and behaving) popular Internet location. Needless, to say this request more than on occasion finds itself on Google servers. <br /> <br /> So 'Hello World!' for programming languages seems to transform to 'Hello Google!' for understanding how web application security related tools work. Let us see, how JBroFuzz does it. <br /> <br /> • Double-click on JBroFuzz and browse to the 'Fuzzing' tab <br /> <br /> JBroFuzz is constituted of tabs, typically located in the bottom or top (if you bother to change the settings) of the main window. <br /> <br /> The 'Fuzzing' tab is where you craft your request message to a particular host. Once that is in place, you can select any part of the request and proceed into adding any number of payloads. We shall see how in later sections. <br /> <br /> • In the 'URL' field type: http://www.google.com/ http://www.google.com <br /> <br /> Unlike conventional URLs, the URL field in JBroFuzz is only used for the underlying protocol (HTTP or HTTPS), host name (e.g. www.yahoo.com) and (optionally) port number. <br /> <br /> All remaining information pasted or typed into the 'URL' field will be ignored; you are expected to enter it in the 'Request' field below. <br /> <br /> &lt;nowiki&gt;Still, if you want to just copy-paste a URL from a browser, hit [Ctrl+L] while you are not fuzzing, paste the URL value that you have copied from a browser and JBroFuzz will automatically do the work for you. &lt;/nowiki&gt; <br /> <br /> Examples of valid URL values to be put in the <br /> <br /> Treat the 'URL' and 'Request' fields as the two stages of a 'telnet' session on port 80; you are effectively using the 'URL' field to specify the equivalent of: <br /> <br /> &lt;tt&gt;&amp;gt;telnet www.google.com 8088&lt;/tt&gt; <br /> <br /> As equivalent to: <br /> <br /> &lt;code&gt;http://www.google.com:8088&lt;br&gt; &lt;/code&gt; <br /> <br /> or in the case of HTTPS: <br /> <br /> &lt;code&gt;https://www.google.com:8088&lt;br&gt; &lt;/code&gt; <br /> <br /> Naturally, default ports for HTTP is 80 and HTTPS is 443. <br /> <br /> • In the 'Request' field type: <br /> <br /> &lt;code&gt;GET / HTTP/1.0&lt;br&gt; &lt;br&gt; &lt;/code&gt; <br /> <br /> And press 'Enter' twice <br /> <br /> This is where the body of the message you are sending is to be placed. So anything obeying HTTP/S protocol, such as GET and POST requests, header fields and/or HTML content should be included here. <br /> <br /> As part of the process of fuzzing web applications with JBroFuzz you need to have done your homework, in terms of providing a base request message. This message is what will be used later on to add payloads to particular sections of the request. <br /> <br /> &lt;nowiki&gt;• Hit 'Start' [Ctrl+Enter]&lt;/nowiki&gt; <br /> <br /> This will instigate the process of sending a single request to the specified host on a given (or default) port, over HTTP or HTTPS. <br /> <br /> Once a connection has been established JBroFuzz will proceed to submit the message you have typed into the 'Request' field. <br /> <br /> Finally, JBroFuzz will log all data sent and received into a file; accessing this file is typically a process of double clicking on the output line on the table at the bottom section of the 'Fuzzing' tab. <br /> <br /> You should see a response received in the bottom part of the 'Fuzzing' panel. Double click (or right click for more options) to see the information exchanged; typically this would be a 302 redirect pointing you to another location. Congratulations, you have just said &quot;Hello&quot; to Google! <br /> <br /> [[Image:002-JBroFuzz-Tutorial.png|500px|JBroFuzz Hello Google!]] <br /> <br /> Now this would typically be enough under RFC rules, to get a response back; but damn all the bots out here, most websites require further information to respond back. So, in the 'Request' field let's pretend to be a (kind of) legitimate browser by typing: <br /> <br /> &lt;code&gt;GET / HTTP/1.0&lt;br&gt; Host: www.google.com&lt;br&gt; User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729) JBroFuzz/1.5&lt;br&gt; Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-gb,en;q=0.5Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7&lt;br&gt; &lt;br&gt; &lt;/code&gt; <br /> <br /> Not forgetting to end the request typed with two returns: Press 'Enter' twice. Again, you should be able to see a line added with the response received back. <br /> <br /> Practice sending single requests to a website of your choice by changing the URL and also the 'Host:' field from the 'Request' above. Also try accessing an HTTPS website. <br /> <br /> &lt;nowiki&gt;Alternatively, you can use the shortcut [Ctrl+L] to type in your URL, with the 'Request' field filled automatically, based on the URL you have typed. &lt;/nowiki&gt; &lt;br&gt; <br /> <br /> === HTTP Version Numbers &amp;amp; www.cia.gov Headerless Responses ===<br /> <br /> For web applications, very often ill-defined requests submitted over the Internet, will trigger semi-legitimate responses that actually do not obey HTTP RFC protocol specification. Often, even though this is not the case in this example, these responses can lead to the identification of one or more security vulnerabilities. <br /> <br /> In this example we test for the responses received for invalid HTTP version numbers on a particular website, namely www.cia.gov, over https. Now a word of caution here; please do not attempt to fuzz web applications that you do not have the authority to do so, especially over the Internet. <br /> <br /> Still, for the purposes of this tutorial exercise, we will subject a web server to no more than a dozen or so requests. These requests would be otherwise identical, if it was not for the HTTP version number incrementing by a value of 1 on each request. <br /> <br /> In terms of having the authority to do so, well this is identical to hitting 'Refresh' in your web browser a dozen or so times, while you are browsing to www.cia.gov. I do not consider this remotely close to any form of hacking, cracking, or proper fuzzing; web servers across the globe receive a lot more abuse than this on a daily basis. <br /> <br /> Finally, by the time you are reading this, the particular issue described might have been fixed. So here goes: <br /> <br /> • Within JBroFuzz, select: <br /> <br /> &lt;code&gt;File -&amp;gt; Open Location [Ctrl+L]&lt;br&gt; &lt;/code&gt; <br /> <br /> Type: https://www.cia.gov and hit enter. This is depicted in the following screenshot: <br /> <br /> [[Image:003-JBroFuzz-Tutorial.png|JBroFuzz Open Location]] <br /> <br /> Hitting 'Enter' should automatically populate the 'URL' field and the 'Request' field within the 'Fuzzing' tab. What you see is the base request that we intend to add fuzzing payloads to. Before we do so, let us make one small alteration first: <br /> <br /> • Modify the first line of the 'Request' field to: <br /> <br /> &lt;code&gt;GET / HTTP/0.0&lt;br&gt; &lt;/code&gt; <br /> <br /> Our objective is to enumerate the supported by the web server (in this case www.cia.gov) HTTP version numbers, following the two digit format that it has. We could be a lot more agressive here and test for buffer overflows and all types of injection; that would be out of line without the authority to do so. Instead we are going to see how JBroFuzz will iterate through the values of 0.0 to 1.4 by means of adding a Fuzzer to our base request. <br /> <br /> • Highlight the second zero from the line 'GET / HTTP/0.0' and right-click, selecting 'Add'. This is depicted in the screeshot below: <br /> <br /> [[Image:004-JBroFuzz-Tutorial.png|400px|Adding a Fuzzer to the HTTP version number]] <br /> <br /> • From the appearing 'Add a Fuzzer' window, select as 'Category Name', in the most left column 'Base' and as 'Fuzzer Name' in the middle column 'Base 10 (Decimal) Alphabet. <br /> <br /> • Click on 'Add Fuzzer' on the bottom right of the window <br /> <br /> [[Image:005-JBroFuzz-Tutorial.png|400px|Adding a Fuzzer]] <br /> <br /> This should add a Fuzzer of length 1 that iterates over the decimal (i.e. base 10) numbers 0 to 9. If we have added a hexadecimal Fuzzer instead of a decimal one (i.e. base 16) the iteration would from 0 to F. If we had selected two digits instead of one and proceeded to add a decimal Fuzzer, the iteration would be from: <br /> <br /> &lt;code&gt;00&lt;br&gt; 01&lt;br&gt; ..&lt;br&gt; 98&lt;br&gt; 99&lt;br&gt; &lt;/code&gt; <br /> <br /> From a User Interface (UI) perspective you should see a line added to the 'Added Payloads Table'. <br /> <br /> • Click 'Start' [Ctrl+Enter] <br /> <br /> This process will send 10 requests to the specified web server changing only first line of the request to: <br /> <br /> &lt;code&gt;GET / HTTP/0.0...&lt;br&gt; GET / HTTP/0.1...&lt;br&gt; ...&lt;br&gt; GET / HTTP/0.8...&lt;br&gt; GET / HTTP/0.9...&lt;br&gt; &lt;/code&gt; <br /> <br /> While this is ongoing, you can sort the results by 'No' in the 'Output' table in the bottom of the 'Fuzzing' tab. This should enable you to see what request is currently being transmitted and received in real time. <br /> <br /> Once complete, change the first line of the 'Request' field to read: <br /> <br /> &lt;code&gt;GET / HTTP/1.0&lt;br&gt; &lt;/code&gt; <br /> <br /> • Click 'Start' [Ctrl+Enter] <br /> <br /> The resulting output should resemble the following screenshot: <br /> <br /> [[Image:006-JBroFuzz-Tutorial.png|500px|JBroFuzz Output from a Fuzzing Session]] <br /> <br /> Straight away we can notice a difference in the response size: For HTTP version numbers 0.0 to 0.9 we are getting back what seems fairly big in size responses; 32222 bytes in size worth of responses, given that HTTP protocol version 0.0 to 0.8 do not officially exist! <br /> <br /> By double-clicking on one of these requests, we can see that the web server in question is responding back with no headers, yet returning a full HTML body; this represents the 32222 bytes of response of data we are receiving back. The following screenshot illustrates this: <br /> <br /> [[Image:007-JBroFuzz-Tutorial.png|300px|JBroFuzz Output for a Single Request/Response]] <br /> <br /> Using the 'Graphing' tab we can proceed to graph the particular requests and responses for this given session. <br /> <br /> • Within the 'Graphing' tab, click 'Start' [Ctrl+Enter]. <br /> <br /> • Select the directory corresponding to the Output folder we have used for this fuzzing session. This will typically be the last one. <br /> <br /> • Right-click and select 'Graph' <br /> <br /> Once complete, browse to the 'Response Size' tab within the 'Graphing' tab, as illustrated in the screenshot below: <br /> <br /> [[Image:008-JBroFuzz-Tutorial.png|300px|JBroFuzz Graphing different 'Response Sizes']] <br /> <br /> To re-iterate this does not present a security vulnerability in any shape or form; merely the fact that by manipulating HTTP version numbers as part of the request we transmit, we can impact the response that we get back. In this case, what changes is the non-existent header fields, with some HTML content being received back. <br /> <br /> If I was to guess what is causing this, I would say that some sort of load balancing or content delivery is not happening as it should when non-existent version numbers are being transmitted. <br /> <br /> == Using JBroFuzz with a Generic Proxy ==<br /> <br /> JBrofuzz 2.0 and subsequent releases include generic proxy support. As of this writing, basic authentication is supported with plans to eventually support NTLM and Kerberos authentication as well. We've tried to make the use of a proxy as straight forward as possible. All arguments for the proxy can be passed in the URL field and will take one of the following forms. <br /> &lt;pre&gt;Without Authentication: &amp;lt;proxy server&amp;gt;:&amp;lt;proxy port&amp;gt;<br /> With Authentication: &amp;lt;proxy username&amp;gt;:&amp;lt;proxy password&amp;gt;@&amp;lt;proxy server&amp;gt;:&amp;lt;proxy port&amp;gt;<br /> &lt;/pre&gt; <br /> The structure of the request field and whether the GET parameter contains an absolute URL depends on the proxy you are using. For this reason, you may have to do a bit of trial and error to determine what format(s) your proxy accepts. To make all of this a bit clearer lets look at a couple of examples. <br /> <br /> === Squid Proxy ===<br /> <br /> In the first example, we are fuzzing through a squid proxy that requires ncsa user authentication as shown in the figure below. When producing similar results, its important that you use your own proxy and not the one shown in the figure. This proxy was setup for demonstration purposes, will not accept connections from your IP address, and the credentials will no longer be active. <br /> <br /> [[Image:016-JBroFuzz-Tutorial.jpg|503x449px]] <br /> <br /> === Paros Proxy ===<br /> <br /> In the second example, we are fuzzing through a local Paros proxy running on port 8080 that does not require user authentication. Notice the difference in the syntax of the URL field when user authentication is not required. <br /> <br /> [[Image:017-JBroFuzz-Tutorial.jpg|503x449px]] <br /> <br /> In the third example, we are still fuzzing through Paros, but notice the slight difference in the Request Field. Specifically, pay special attention to the GET line. We are no longer including the fully qualified path. Unlike Squid, Paros will accept both formats. Keep this in mind when you are performing initial testing with JBroFuzz and the proxy of your choice. <br /> <br /> [[Image:018-JBroFuzz-Tutorial.jpg|503x449px]]<br /> <br /> === Burp Proxy ===<br /> In the final example, we are fuzzing through Burp. Similar to Squid, Burp requires absolute URLs in the request. A successful Burp request is shown below.<br /> <br /> [[Image:019-JBroFuzz-Tutorial.jpg|503x449px]]<br /> <br /> == Using JBroFuzz with Paros Proxy ==<br /> <br /> JBroFuzz is a standalone fuzzer; it can release and create sockets over HTTP and HTTPS, but in order to use JBroFuzz correctly you will have to know what it is that you are fuzzing. <br /> <br /> In comes the need for a proxy tool; the opening versions of JBroFuzz actually had a proxy tab that you could use to intercept traffic generated by your web browser. That functionality got removed in an attempt to focus and deliver solely on the fuzzing capabilities of the tool. <br /> <br /> This section details how to use JBroFuzz in combination with a client side proxy. The one selected is Paros Proxy, which, despite the fact that it hasn't been updated since 2006 is still a popular tool that you see in web security testing live CDs. You could use any of the other proxy tools available. <br /> <br /> === Winning on a Remix of the Year Award ===<br /> <br /> At 17:53, on a frosty winter evening, a message window popped up: <br /> &lt;pre&gt;17:53 http://www.localhost.com/remixcontest/club/annual2010.html<br /> 17:53 Hey bro, could you cast in a vote here for the Such &amp;amp; Such Remix?<br /> 17:53 Appreciated!<br /> &lt;/pre&gt; <br /> A friend in need is a friend indeed, so here goes I thought. Opening up a web browser configured to work with Paros as an intermediate proxy, allowed for the casting of my vote. while keeping a record of each request and reply. <br /> <br /> No registration, or any other form of submitting an identifier was needed. The request that Paros stored for the casting of the actual vote was: <br /> &lt;pre&gt;GET http://www.localhost.com/remixcontest/club/vote.php?onLoad=%5Btype%20Method%5D&amp;amp;id=55 HTTP/1.1<br /> Host: www.localhost.com<br /> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729) Paros/3.2.13<br /> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8<br /> Accept-Language: en-gb,en;q=0.5<br /> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7<br /> Keep-Alive: 300<br /> Proxy-Connection: keep-alive<br /> Cookie: PHPSESSID=ab6afb883dbgf8084f6dcf1eafdb225e<br /> &lt;/pre&gt; <br /> Paros Proxy actually places the domain (in this case www.localhost.com) with the protocol (i.e. http) in front of the GET request. As a result, you can't open a telnet/netcat session and just copy-paste the above. Similarly when we bring the request into JBroFuzz, a bit of tweaking is required. <br /> <br /> *In the URL field, type:<br /> &lt;pre&gt;http://www.localhost.com<br /> &lt;/pre&gt; <br /> In the Request field, let's keep what is of interest: <br /> &lt;pre&gt;GET /remixcontest/club/vote.php?onLoad=%5Btype%20Method%5D&amp;amp;id=55 HTTP/1.0<br /> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5<br /> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8<br /> Accept-Language: en-gb,en;q=0.5<br /> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7<br /> Cookie: PHPSESSID=ab6afb883dbgf8084f6dcf1eafdb225e<br /> &lt;/pre&gt; <br /> No needs for Keep-Alive and Proxy-Connection. Let's simplify the HTTP request by making it a version 1.0 request and getting rid of the Host header as well. Also on the user agent, let us keep that mainstream vanilla: Firefox on Windows (popular browser combination), getting rid of the .NET and Paros additives. <br /> <br /> Checking on the website, our Such &amp;amp; Such remix already has about 100 votes or so and the top remix has approximately 310 votes. Let's fuzz this: <br /> <br /> *Select 2 of the digits of the cookie value:<br /> &lt;pre&gt;PHPSESSID=ab6afb883dbgf8084f6dcf1eafdb225e<br /> &lt;/pre&gt; <br /> *Select: Panel -&amp;gt; Add<br /> <br /> *In the &quot;Add a Fuzzer&quot; panel, select:<br /> &lt;pre&gt;Base -&amp;gt; Base16 (HEX)<br /> &lt;/pre&gt; <br /> and select &quot;Add Fuzzer&quot;. <br /> <br /> This will add a line within the Payloads tab on the right hand side. <br /> <br /> Our cookie value above (PHPSESSID=ab6afb883dbgf8084f6dcf1eafdb225e) is in lowercase, hexadecimal format. Let's make sure the encoding we select is also that. <br /> <br /> Within the Payloads tab, click on the encoding drop down menu and select lowercase. Just before clicking &quot;Start&quot;, JBroFuzz should look something like the screenshot below. <br /> <br /> [[Image:014-JBroFuzz-Tutorial.png|Adding Votes by iterating through PHPSESSID cookie values]] <br /> <br /> == Performing User Enumeration with a Valid Set of Credentials ==<br /> <br /> Often you encounter an application that allows for the enumeration of one or more pages after a user has been successfully granted a set of session credentials. One of the key areas to test from an application specific perspective, relates to the page(s) that provide user account information. <br /> <br /> In the following example, we investigate an ASP.NET 2.0 application with a C# back-end. In this, an authenticated user has the option to select to &quot;View My Profile&quot;. This page provides them with account information (including the typical username, email address, further notes) that they can proceed to update and save to the back-end system. <br /> <br /> After a user has authenticated, the following URL, gives them access to their profile information stored on the database: <br /> &lt;pre&gt;http://www.myattackingdomain.com/portal-location/UserInfo.aspx?UserID=23<br /> &lt;/pre&gt; <br /> Simple investigation confirms that the digits allowed as part of the UserID value are decimal numbers only. Lets feed that information into JBroFuzz. <br /> <br /> === Fuzzing a User ID ===<br /> <br /> • Within JBroFuzz, select: <br /> <br /> &lt;code&gt;File -&amp;gt; Open Location [Ctrl+L]&lt;br&gt; &lt;/code&gt; <br /> <br /> Type: http://www.myattackingdomain.com/portal-location/UserInfo.aspx?UserID=23 and hit enter. This is depicted in the following screenshot: <br /> <br /> [[Image:009-JBroFuzz-Tutorial.png|300px|JBroFuzz 'GET' Request with a 'UserID' parameter]] <br /> <br /> From the URL the important parameter is the value of the UserID query string (the value 23, above). We want to fuzz that. <br /> <br /> • Within the Fuzzing Tab, in the &quot;Request&quot; text area, highlight the above number 23 • Right-click and select &quot;Add&quot; <br /> <br /> In the &quot;Add a Fuzzer&quot; window that appears, select: <br /> <br /> • Category Name: &lt;code&gt;Base&lt;/code&gt; • Fuzzer Name: &lt;code&gt;Base10 (DEC)&lt;/code&gt; • Select &quot;Add Fuzzer&quot; in the bottom right <br /> <br /> This would have added a decimal (base 10 fuzzer) of length 2 onto the location. <br /> <br /> • You will see a row added within the &quot;Added Fuzzers Table&quot; of the Fuzzing panel. • Click &quot;Start&quot; &lt;code&gt;Ctrl+Enter&lt;/code&gt; <br /> <br /> This will transmit 100 requests to the domain in question, which in this case is assumed: www.myattackingdomain.com. The value being changed within each request will be: <br /> &lt;pre&gt;• GET /portal-location/UserInfo.aspx?UserID=00 HTTP/1.0<br /> • GET /portal-location/UserInfo.aspx?UserID=01 HTTP/1.0<br /> ...<br /> • GET /portal-location/UserInfo.aspx?UserID=98 HTTP/1.0<br /> • GET /portal-location/UserInfo.aspx?UserID=99 HTTP/1.0<br /> &lt;/pre&gt; <br /> Done. Let's proceed to graph the responses that we have obtained. Our objective is to understand which two-digit numbers from 00 to 99 correspond to valid user accounts. <br /> <br /> === Graphing Results ===<br /> <br /> • Within the &quot;Graphing&quot; tab, click &quot;Start&quot; &lt;code&gt;Ctrl+Enter&lt;/code&gt; <br /> <br /> A list of directories will appear on the left-hand side. If you scroll to the bottom of the list you should see the directory corresponding to your fuzzing session, in our case it was (175 2009-06-24 16-18-24) <br /> &lt;pre&gt;• Right-click on (175 2009-06-24 16-18-24)<br /> • Click &quot;Graph&quot;<br /> &lt;/pre&gt; <br /> This will generate the graphs in their respective tabs. The question now becomes which graph is of interest for our user enumeration exercise. <br /> <br /> By definition enumerating users against an ID value, or any other identifier involves being able to obtain a different response for an existing user to that of a user that is not have a corresponding ID value. <br /> <br /> Thus, from the metrics available, the one useful for enumerating users will be that of measuring the &quot;Hamming Distance&quot; between responses received. Based on the JBroFuzz documentation: <br /> <br /> '''Fuzzing Hamming Distance ''' <br /> &lt;pre&gt;A bar chart with the hamming distance of the characters in the response, <br /> relative to the first response received. Check each character of the first<br /> response received, against the character at the same position of the<br /> current response received. If they are not identical, increment the <br /> hamming distance.<br /> &lt;/pre&gt; <br /> As we can see the Fuzzing Hamming Distance (FHD) varies quite a bit from the definition of the normal hamming distance term, used in telecommunications. Still, they share a lot of similarities. <br /> <br /> As we can from the above, the first request is critical to calibrating our user enumeration exercise. It represents the value that all other Fuzzing Hamming Distances (FHD) will be measured and normalised towards. For the java-skilled audience, the algorithm is quite trivial, but offers spectacular results in distinguishing responses: <br /> &lt;pre&gt;in = new BufferedReader(new FileReader(f));<br /> 58 <br /> 59 int counter = 0;<br /> 60 int check = 0;<br /> 61 int c;<br /> 62 while (((c = in.read()) &amp;gt; 0) &amp;amp;&amp;amp; (counter &amp;lt; MAX_CHARS)) {<br /> 63 <br /> 64 // If we are passed &quot;--jbrofuzz--&amp;gt;\n&quot; in the file<br /> 65 if (check == END_SIGNATURE.length()) {<br /> 66 <br /> 67 firstSet.append((char) c);<br /> 68 <br /> 69 }<br /> 70 // Else find &quot;--jbrofuzz--&amp;gt;\n&quot; using a counter<br /> 71 else {<br /> 72 // Increment the counter for each success<br /> 73 if (c == END_SIGNATURE.charAt(check)) {<br /> 74 check++;<br /> 75 } else {<br /> 76 check = 0;<br /> 77 }<br /> 78 }<br /> 79 <br /> 80 counter++;<br /> 81 <br /> 82 }<br /> 83 in.close();<br /> &lt;/pre&gt; <br /> Ergo, the corresponding graph is depicted in the screenshot below. The peak graphs correspond to number that if you hover the mouse over will give you the enumeration ID of a valid user. <br /> <br /> [[Image:015-JBroFuzz-Tutorial.png|500px|Measuring Hamming Distance for User Enumeration]] <br /> <br /> == Eliminating False Positives: LDAP Injection ==<br /> <br /> Every now and then a tool (that does not produce false positives) will hit an application reporting back a huge variety of (hopefully not confirmed, but pending further investigation) injection findings. <br /> <br /> Due to the limited number of characters required in performing LDAP Injection, such issues will be high on that list. But let's refresh our memory a bit of how LDAP injection works:<br /> <br /> http://www.owasp.org/index.php/LDAP_injection<br /> <br /> So typically, during an automated scan, negating LDAP cn-type queries would be submitted and their responses noted. Example:<br /> <br /> &lt;pre&gt;<br /> GET /myfilelocation.jsp?lang=en&amp;city=user)(sn=*&amp;rid=97 HTTP/1.1<br /> ...<br /> &lt;/pre&gt;<br /> <br /> vs.<br /> <br /> &lt;pre&gt;<br /> GET /myfilelocation.jsp?lang=en&amp;city=user)!(sn=*&amp;rid=97 HTTP/1.1<br /> ...<br /> &lt;/pre&gt;<br /> <br /> or <br /> <br /> &lt;pre&gt;<br /> GET /myfilelocation.jsp?lang=en&amp;city=admin*)((|userpassword=*)&amp;rid=97 HTTP/1.1<br /> ...<br /> &lt;/pre&gt;<br /> <br /> As great as this check might be from an LDAP perspective, it has a high likelihood of generating false positives, due to the character sets being used. Ergo, a protection mechanism (silly worst-case blacklist present for example) would typically hunt down cross-site scripting and sql injection type of characters:<br /> <br /> &lt;pre&gt;<br /> &lt; &gt; ' etc.<br /> &lt;/pre&gt;<br /> <br /> Not considering =, *, or brackets as completely bad (he says). <br /> <br /> === What characters are allowed through? ===<br /> <br /> Enough of all that; we want to know what responses are allowed back and what's different about them for all characters being filtered through a black-list.<br /> <br /> Let's transform the above GET into the following and proceed to add a single fuzzer that tells us that:<br /> <br /> &lt;pre&gt;<br /> GET /myfilelocation.jsp?lang=en&amp;city=X&amp;rid=97 HTTP/1.1<br /> &lt;/pre&gt;<br /> <br /> Now in the position of the X character, proceed to add an ASCII 94 Alphabet Fuzzer (available in version 2.1 and above). This will check the responses for all characters which are printable ASCII, with the exception of space.<br /> <br /> In total there are 95 printable ASCII characters; minus the one present for space (yes, the one you hit all the time, every day) leaves 94. This fuzzer produces each of those values, in incrementing ASCII order.<br /> <br /> [[Image:020-JBroFuzz-Tutorial.png|500px|Measuring Size Length for Single Character ASCII 94 Fuzzing]] <br /> <br /> Based on the above graph, the following responses trigger a different response size. Thus the characters blocked by a black-list are:<br /> <br /> &lt;pre&gt;<br /> ! &quot; , &lt; &gt; @ [ \ ] ^ ` { | } ~<br /> &lt;/pre&gt;<br /> <br /> Interesting. Know any payloads that can evade those?<br /> :)<br /> <br /> == JBroFuzz Development Corner ==<br /> <br /> This section presents how to setup and use JBroFuzz as a fuzzing library. Also, it offers an insight in how to setup and compile your own version of JBroFuzz. As different people have different levels of expertise of the java programming language, eclipse, ant and subversion, some of the steps presented herein might be considered basic by advanced developers. <br /> <br /> === Setting up a JBroFuzz Development Environment ===<br /> <br /> This section guides you towards setting up a development environment for JBroFuzz. Despite the Operating System (O/S) being windows XP, a similar process can be followed in a number of other O/S. <br /> <br /> You will need to have installed: <br /> <br /> *Tortoise SVN (using TortoiseSVN-1.6.6.17493-win32-svn-1.6.6.msi) <br /> *Eclipse Java (using eclipse-java-galileo-SR1-win32.zip)<br /> <br /> Optionally, if you don't like building your application through eclipse you could also require to install Apache Ant. <br /> <br /> ==== Step 1: Obtain the source code ====<br /> <br /> JBroFuzz uses SubVersion with the repository being publicly available for download through anonymous access on sourceforge. There is a plan to move it the source to the OWASP Git repository, but until then, use the guidelines below. <br /> <br /> [[Image:010-JBroFuzz-Tutorial.png|Tortoise SVN Check out JBroFuzz Source Code]] <br /> <br /> Right click on the folder location where you want to download the source code and select: <br /> <br /> *SVN Checkout<br /> <br /> In the &quot;URL of repository&quot;, enter: <br /> &lt;pre&gt;https://jbrofuzz.svn.sourceforge.net/svnroot/jbrofuzz<br /> &lt;/pre&gt; <br /> In the &quot;Checkout directory&quot;, enter the folder location of your choice, in this case: <br /> &lt;pre&gt;C:\root\code\jbrofuzz<br /> &lt;/pre&gt; <br /> In the &quot;Checkout Depth&quot; select: <br /> <br /> *Fully recursive<br /> <br /> Untick &quot;Omit Externals&quot; (should be unticked by default) <br /> <br /> In the &quot;Revision&quot; select: <br /> <br /> *&quot;Head revision&quot;<br /> <br /> Select OK. <br /> <br /> This process, once complete will checkout the entirety of the JBroFuzz source code from the SVN repository on sourceforge. <br /> <br /> ==== Step 2: Configuring a JBroFuzz Project within Eclipse ====<br /> <br /> Having obtained the latest copy of the source code, the next step entails importing that source code within the Eclipse IDE. <br /> <br /> Within Eclipse, select: <br /> &lt;pre&gt;File -&amp;gt; New -&amp;gt; Other<br /> &lt;/pre&gt; <br /> From the &quot;New&quot; panel that appears, select: <br /> &lt;pre&gt;Java -&amp;gt; Java Project from Existig Ant Buildfile<br /> &lt;/pre&gt; <br /> [[Image:011-JBroFuzz-Tutorial.png|Import JBroFuzz Code into Eclipse from Ant File]] <br /> <br /> Select &quot;Next&quot;. <br /> <br /> In the next menu, under &quot;Ant buildfile&quot;, select &quot;Browse&quot;. <br /> <br /> Browse to the location where you have just (step 1) downloaded the source code and select the following file: <br /> <br /> *build.xml<br /> <br /> The build.xml file is an Ant build file that JBroFuzz uses. <br /> <br /> [[Image:012-JBroFuzz-Tutorial.png|Select the Ant File]] <br /> <br /> Selecting that file should have populated the &quot;Project name&quot; as jbrofuzz and also given you: <br /> <br /> &lt;br&gt; <br /> &lt;pre&gt;&quot;javac&quot; task found in target &quot;compile&quot;<br /> &lt;/pre&gt; <br /> MAKE SURE TO TICK: <br /> <br /> *&quot;Link to the buildfile in the filesystem&quot;<br /> <br /> Otherwise eclipse will try to replicate the source code within your workspace and that makes the process a tiny bit more complicated when it comes to actually building JBroFuzz. <br /> <br /> Click &quot;Finish&quot; <br /> <br /> You will see the item &quot;Building workspace (76%) on the bottom right hand side of Eclipse. Once that is complete, you should see the jbrofuzz project on the top left corner of the Package Explorer within Eclipse. <br /> <br /> ==== Step 3: Building JBroFuzz ====<br /> <br /> Within the Package Explorer, expand the jbrofuzz project and double-click on the build.xml file. <br /> <br /> Right click on the &quot;build [default]&quot; task within the &quot;Outline&quot; window (typically seen on the right hand side) and select: <br /> &lt;pre&gt;Run As -&amp;gt; 1. Ant Build [Alt+Shift+X, Q]<br /> &lt;/pre&gt; <br /> If the build has been successful, a JBroFuzz.jar file within the the /jar folder would have been created. Following the path conventions above that should be in: <br /> &lt;pre&gt;C:\root\code\jbrofuzz\jar\JBroFuzz.jar<br /> &lt;/pre&gt; <br /> [[Image:013-JBroFuzz-Tutorial.png|Building JBroFuzz within Eclipse]] <br /> <br /> === How to Use JBroFuzz as a Fuzzing Library ===<br /> <br /> Quite often what you need to do in terms of fuzzing, far exceeds the User Interface (UI) of JBroFuzz. For this reason, a set of core fuzzing APIs have been made available that can be used for more advanced fuzzing scenarios. <br /> <br /> The JBroFuzz.jar standalone archive (made available with every release) carries a core fuzzing library that holds a number of key classes. These are located under: <br /> &lt;pre&gt;org.owasp.jbrofuzz.core.*;<br /> -Database.java<br /> -Fuzzer.java<br /> -FuzzerBigInteger.java<br /> -NoSuchFuzzerException.java<br /> -Prototype.java<br /> &lt;/pre&gt; <br /> The class of importance is Fuzzer.java. If you are going to use recursive iterators of great length, there is also FuzzerBigInteger.java. The difference between the two is that Fuzzer.java uses the primitive java data type long (up to 16^16 values) while FuzzerBigInteger.java uses java BigInteger to perform the counting. Naturally, the class FuzzerBigInteger is slower and takes more memory than the Fuzzer class. <br /> <br /> Within JBroFuzz a Fuzzer is an instance of a java Iterator. This implies that values can be accessed by simply calling the &lt;code&gt;next()&lt;/code&gt; method once an object has been made available. Typically, a call to &lt;code&gt;hasNext()&lt;/code&gt; should also be performed prior to avoid an exception being thrown. <br /> <br /> A Fuzzer can be obtained from the factory method &lt;code&gt;createFuzzer(String, int);&lt;/code&gt; available for every instance of the fuzzing Database. Ergo: <br /> <br /> ==== A HelloFuzzer Example ====<br /> &lt;pre&gt;Database myDatabase = new Database();<br /> <br /> Fuzzer myFuzzer = myDatabase.createFuzzer(&quot;031-B16-HEX&quot;, 5);<br /> &lt;/pre&gt; <br /> So how do I use the API? Here is a simple HelloFuzzer (file called HelloFuzzer.java) example: <br /> &lt;pre&gt;import org.owasp.jbrofuzz.core.*;<br /> <br /> public class HelloFuzzer {<br /> <br /> public static void main(String[] args) {<br /> <br /> Database fuzzDB = new Database();<br /> <br /> try {<br /> for(Fuzzer f = fuzzDB.createFuzzer(&quot;031-B16-HEX&quot;, 4); f.hasNext();) {<br /> // Get the next payload value...<br /> System.out.println(&quot; The fuzzer payload is: &quot; + f.next());<br /> }<br /> } catch (NoSuchFuzzerException e) {<br /> System.out.println(&quot;Could not find fuzzer &quot; + e.getMessage());<br /> }<br /> <br /> }<br /> <br /> } // HelloFuzzer.java OWASP JBroFuzz Example 1<br /> &lt;/pre&gt; <br /> To compile the above use: <br /> &lt;pre&gt;javac -classpath &quot;.\jbrofuzz\jar\JBroFuzz.jar&quot; HelloFuzzer.java<br /> &lt;/pre&gt; <br /> This assumes that you are currently inside the directory where HelloFuzzer.java resides and that the JBroFuzz.jar is located two directories within your current location i.e. in jbrofuzz/jar. In order to run the above compiled HelloFuzzer class issue: <br /> &lt;pre&gt;java -cp &quot;.\jbrofuzz\jar\JBroFuzz.jar;.&quot; HelloFuzzer<br /> &lt;/pre&gt; <br /> Note: The above 2 commands have been crafted in a win32 environment. The process for compiling and running HelloFuzzer.java above is the same in *nix machines. Simply replace the backslash &quot;\&quot; with &quot;/&quot;. <br /> <br /> ==== Fuzzing Payload Definitions ====<br /> <br /> Within the JBroFuzz.jar file, there is a file called fuzzers.jbrf that carries all the fuzzer definitions that you see in the UI payloads tab of JBroFuzz. To view a latest copy of this file you can browse the SVN repository of JBroFuzz: <br /> &lt;pre&gt;http://jbrofuzz.svn.sourceforge.net/viewvc/jbrofuzz/tar/fuzzers.jbrf?view=log<br /> &lt;/pre&gt; <br /> A note here worth mentioning: Files ending in .jbrofuzz are session files saved by users while performing fuzzing operations. Files ending in .jbrf are JBroFuzz system files. Typical examples of .jbrf files are headers.jbrf, as well as fuzzers.jbrf. Both these use an internal proprietary format not to be confused with the .jbrofuzz file format. <br /> <br /> Fuzzers belong in categories (1 to many) and each fuzzer carries a set of payloads that define the alphabet of the fuzzer. <br /> <br /> Also, you have replacive and recursive fuzzers, zero fuzzers, etc. There are a number of different fuzzer categories. As an example of a fuzzer within the fuzzers.jbrf file, consider the hexadecimal fuzzer: <br /> &lt;pre&gt;Fuzzer Name: Base16 (HEX)<br /> Fuzzer Type: Recursive<br /> Fuzzer Id: 031-B16-HEX<br /> <br /> Total Number of Payloads: 16<br /> &lt;/pre&gt; <br /> Within the fuzzers.jbrf file this fuzzer is defined in plain-text format as follows: <br /> &lt;pre&gt;R:031-B16-HEX:Base16 (HEX):16<br /> &amp;gt; Number Systems | Base | Recursive Fuzzers<br /> 0<br /> 1<br /> 2<br /> 3<br /> 4<br /> 5<br /> 6<br /> 7<br /> 8<br /> 9<br /> a<br /> b<br /> c<br /> d<br /> e<br /> f<br /> &lt;/pre&gt; <br /> &lt;br&gt; There is very little preventing you from defining your own fuzzers within this file, by following the file format specified above. You can use the UI to see if they have been loaded successfully. <br /> <br /> Further to recursive and replacive fuzzers you also have zero fuzzers (i.e. a zero fuzzer of 1000 will just transmit 1000 requests as they are, without adding any payloads) double fuzzers, cross product fuzzers, etc. <br /> <br /> Notice the factory method Database.createFuzzer(&quot;031-B16-HEX&quot;, 4) yielding: &quot;I want a 4 digit recursive fuzzer (why because NUM-HEX is recursive in its definition, starts with R: instead of P:) of HEX digits.&quot; <br /> <br /> Thus the above scenario would iterate through all the digits from 0000 to ffff. I wouldn't recommend using the above scenario for such trivial fuzzing capabilities; simply presented as an example of the inner workings of JBroFuzz.jar <br /> <br /> ==== HelloFuzzer Refined ====<br /> <br /> A more detailed code breakdown of the above HelloFuzzer example can be found below: <br /> &lt;pre&gt;/**<br /> * JBroFuzz API Examples 01<br /> *<br /> * JBroFuzz - A stateless network protocol fuzzer for web applications.<br /> * <br /> * Copyright (C) 2007, 2008, 2009 subere@uncon.org<br /> *<br /> * This file is part of the JBroFuzz API examples on how to use the <br /> * fuzzer libraries included in JBroFuzz.jar.<br /> * <br /> * JBroFuzz is free software: you can redistribute it and/or modify<br /> * it under the terms of the GNU General Public License as published by<br /> * the Free Software Foundation, either version 3 of the License, or<br /> * (at your option) any later version.<br /> * <br /> * JBroFuzz is distributed in the hope that it will be useful,<br /> * but WITHOUT ANY WARRANTY; without even the implied warranty of<br /> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br /> * GNU General Public License for more details.<br /> * <br /> * You should have received a copy of the GNU General Public License<br /> * along with JBroFuzz. If not, see &amp;lt;http://www.gnu.org/licenses/&amp;gt;.<br /> * Alternatively, write to the Free Software Foundation, Inc., 51 <br /> * Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.<br /> * <br /> * Verbatim copying and distribution of this entire program file is <br /> * permitted in any medium without royalty provided this notice <br /> * is preserved. <br /> * <br /> */<br /> <br /> import org.owasp.jbrofuzz.core.NoSuchFuzzerException;<br /> import org.owasp.jbrofuzz.core.Database;<br /> import org.owasp.jbrofuzz.core.Fuzzer; <br /> <br /> /**<br /> * &amp;lt;p&amp;gt;In JBroFuzz a Fuzzer is a java Iterator.&amp;lt;/p&amp;gt;<br /> * <br /> * &amp;lt;p&amp;gt;In order to create a Fuzzer, use the factory method<br /> * Database.createFuzzer(String, int), passing as arguments<br /> * the Fuzzer ID and the specified length as a positive int.&amp;lt;/p&amp;gt;<br /> * <br /> * &amp;lt;p&amp;gt;Be careful to check that the fuzzer ID (labelled as f_ID)<br /> * is actually an existing ID from the Database of Fuzzers.&amp;lt;/p&amp;gt;<br /> * <br /> * &amp;lt;p&amp;gt;Expected Output:&amp;lt;/p&amp;gt;<br /> * &amp;lt;code&amp;gt;<br /> * The fuzzer payload is: 00000&amp;lt;br&amp;gt;<br /> * The fuzzer payload is: 00001&amp;lt;br&amp;gt;<br /> * ...&amp;lt;br&amp;gt;<br /> * (a total of 16^5 = 1048576 lines)&amp;lt;br&amp;gt;<br /> * ...&amp;lt;br&amp;gt;<br /> * The fuzzer payload is: ffffd&amp;lt;br&amp;gt;<br /> * The fuzzer payload is: ffffe&amp;lt;br&amp;gt;<br /> * The fuzzer payload is: fffff&amp;lt;br&amp;gt;<br /> * &amp;lt;/code&amp;gt;<br /> * <br /> * &amp;lt;p&amp;gt;For more information on the Database of Fuzzers, see the<br /> * HelloDatabase Class.&amp;lt;/p&amp;gt;<br /> * <br /> * @author subere@uncon.org<br /> * @version n/a<br /> */<br /> public class HelloFuzzer {<br /> <br /> /**<br /> * @param args<br /> */<br /> public static void main(String[] args) {<br /> <br /> // You have to construct an instance of the fuzzers database<br /> Database fuzzDB = new Database();<br /> // You have to supply a valid fuzzer ID<br /> String f_ID = &quot;031-B16-HEX&quot;;<br /> // You have to supply a (+)tive int<br /> int f_len = 5;<br /> <br /> try {<br /> <br /> for(Fuzzer f = fuzzDB.createFuzzer(f_ID, f_len); f.hasNext();) {<br /> <br /> // Get the next payload value...<br /> System.out.println(&quot; The fuzzer payload is: &quot; + f.next());<br /> <br /> }<br /> <br /> } catch (NoSuchFuzzerException e) {<br /> <br /> System.out.println(&quot;Could not find fuzzer &quot; + e.getMessage());<br /> <br /> }<br /> <br /> }<br /> <br /> }<br /> &lt;/pre&gt; <br /> ==== Hello Database of Fuzzers ====<br /> <br /> Having seen how to access a single Fuzzer through the createFuzzer() method available in the Database object. The next question that comes naturally is what are the Fuzzers that are available by default in JBroFuzz? <br /> <br /> To answer that, this example focuses more on the database component that we previously initialised, investigating the list of available methods that it offers. <br /> <br /> In JBroFuzz, all Fuzzers are stored in a Database object that you will be required to construct in order to access them. <br /> &lt;pre&gt;/**<br /> * JBroFuzz API Examples 02<br /> *<br /> * JBroFuzz - A stateless network protocol fuzzer for web applications.<br /> * <br /> * Copyright (C) 2007, 2008, 2009 subere@uncon.org<br /> *<br /> * This file is part of the JBroFuzz API examples on how to use the <br /> * fuzzer libraries included in JBroFuzz.jar.<br /> * <br /> * JBroFuzz is free software: you can redistribute it and/or modify<br /> * it under the terms of the GNU General Public License as published by<br /> * the Free Software Foundation, either version 3 of the License, or<br /> * (at your option) any later version.<br /> * <br /> * JBroFuzz is distributed in the hope that it will be useful,<br /> * but WITHOUT ANY WARRANTY; without even the implied warranty of<br /> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br /> * GNU General Public License for more details.<br /> * <br /> * You should have received a copy of the GNU General Public License<br /> * along with JBroFuzz. If not, see &amp;lt;http://www.gnu.org/licenses/&amp;gt;.<br /> * Alternatively, write to the Free Software Foundation, Inc., 51 <br /> * Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.<br /> * <br /> * Verbatim copying and distribution of this entire program file is <br /> * permitted in any medium without royalty provided this notice <br /> * is preserved. <br /> * <br /> */<br /> <br /> import org.owasp.jbrofuzz.core.NoSuchFuzzerException;<br /> import org.owasp.jbrofuzz.core.Database;<br /> import org.owasp.jbrofuzz.core.Fuzzer; <br /> <br /> /**<br /> * &amp;lt;p&amp;gt;In JBroFuzz all Fuzzers are stored in a Database<br /> * object that you will be required to construct in order<br /> * to access them.&amp;lt;/p&amp;gt;<br /> * <br /> * &amp;lt;p&amp;gt;Within the Database, each Fuzzer is a collection of <br /> * payloads, which carries a unique ID string value.&amp;lt;/p&amp;gt;<br /> * <br /> * &amp;lt;p&amp;gt;Example ID values are the output of this program:&amp;lt;/p&amp;gt;<br /> * &amp;lt;code&amp;gt;<br /> * The fuzzer ID is: 013-LDP-INJ&amp;lt;br&amp;gt;<br /> * The name of the fuzzer is: LDAP Injection&amp;lt;br&amp;gt;<br /> * The id of the fuzzer is: 013-LDP-INJ&amp;lt;br&amp;gt;<br /> * The of payloads it carries (it's alphabet) is: 20&amp;lt;br&amp;gt;<br /> * It has as 1st payload:&amp;lt;br&amp;gt;<br /> * |&amp;lt;br&amp;gt;<br /> * The fuzzer ID is: 018-XSS-4IE&amp;lt;br&amp;gt;<br /> * The name of the fuzzer is: XSS IE&amp;lt;br&amp;gt;<br /> * The id of the fuzzer is: 018-XSS-4IE&amp;lt;br&amp;gt;<br /> * The of payloads it carries (it's alphabet) is: 38&amp;lt;br&amp;gt;<br /> * It has as 1st payload:&amp;lt;br&amp;gt;<br /> * &amp;lt; img src=`x` onrerror= `&amp;nbsp;;; alert(1) ` /&amp;gt;&amp;lt;br&amp;gt;<br /> *<br /> * &amp;lt;/code&amp;gt;<br /> * <br /> * &amp;lt;p&amp;gt;Do not be confused between Prototypes and Fuzzers; <br /> * JBroFuzz uses Prototype objects to construct the Fuzzers<br /> * that get added into the Database upon initialisation.&amp;lt;/p&amp;gt;<br /> * <br /> * &amp;lt;p&amp;gt;As a result, the getter methods available within a Database<br /> * object can carry the name of getAllPrototypeIDs and <br /> * getAllFuzzerIDs interchangebly.&amp;lt;/p&amp;gt;<br /> * <br /> * @author subere@uncon.org<br /> * @version n/a<br /> */<br /> public class HelloDatabase {<br /> <br /> /**<br /> * @param args<br /> */<br /> public static void main(String[] args) {<br /> <br /> // You have to construct an instance of the fuzzers database<br /> Database fuzzDB = new Database();<br /> <br /> // Get a list of all the fuzzer IDs from the database<br /> String[] fuzzer_IDs = fuzzDB.getAllPrototypeIDs();<br /> <br /> System.out.println(&quot;The fuzzer IDs found are:&quot;);<br /> <br /> for(String fuzzerID&amp;nbsp;: fuzzer_IDs) {<br /> <br /> System.out.println(&quot;The fuzzer ID is: &quot; + fuzzerID);<br /> <br /> // We pass of length of 1, irrelevant if we are<br /> // just going to access the first payload<br /> // of the fuzzer<br /> Fuzzer fuzzer;<br /> try {<br /> <br /> fuzzer = fuzzDB.createFuzzer(fuzzerID, 1);<br /> // Normally you should check for fuzzer.hasNext() <br /> String payload = fuzzer.next();<br /> <br /> System.out.println(&quot;\tThe name of the fuzzer is:\t\t\t&quot; + fuzzer.getName() );<br /> System.out.println(&quot;\tThe id of the fuzzer is:\t\t\t&quot; + fuzzer.getId() );<br /> System.out.println(&quot;\tThe of payloads it carries (it's alphabet) is:\t&quot; + fuzzDB.getSize(fuzzerID));<br /> System.out.println(&quot;\tIt has as 1st payload:\n\t\t&quot; + payload );<br /> <br /> } catch (NoSuchFuzzerException e) {<br /> System.out.println(&quot;Could not find the specified fuzzer!&quot;);<br /> System.out.println(&quot;Going to print all the fuzzer IDs I know:&quot;);<br /> // old vs new for loop&amp;nbsp;:)<br /> // in case of an error, print just the <br /> // fuzzer IDs, accessed from the DB<br /> for(int j = 0; j &amp;lt; fuzzer_IDs.length; j++) {<br /> System.out.println(&quot;The fuzzer ID is: &quot; + fuzzer_IDs[j]);<br /> }<br /> <br /> }<br /> <br /> }<br /> <br /> }<br /> <br /> }<br /> &lt;/pre&gt; <br /> ==== Methods available within the Fuzzer Class ====<br /> <br /> A final example of this section, involves seeing the usage of all the method calls available in the Fuzzer.java class <br /> &lt;pre&gt;/**<br /> * JBroFuzz API Examples 03<br /> *<br /> * JBroFuzz - A stateless network protocol fuzzer for web applications.<br /> * <br /> * Copyright (C) 2007, 2008, 2009 subere@uncon.org<br /> *<br /> * This file is part of the JBroFuzz API examples on how to use the <br /> * fuzzer libraries included in JBroFuzz.jar.<br /> * <br /> * JBroFuzz is free software: you can redistribute it and/or modify<br /> * it under the terms of the GNU General Public License as published by<br /> * the Free Software Foundation, either version 3 of the License, or<br /> * (at your option) any later version.<br /> * <br /> * JBroFuzz is distributed in the hope that it will be useful,<br /> * but WITHOUT ANY WARRANTY; without even the implied warranty of<br /> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br /> * GNU General Public License for more details.<br /> * <br /> * You should have received a copy of the GNU General Public License<br /> * along with JBroFuzz. If not, see &amp;lt;http://www.gnu.org/licenses/&amp;gt;.<br /> * Alternatively, write to the Free Software Foundation, Inc., 51 <br /> * Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.<br /> * <br /> * Verbatim copying and distribution of this entire program file is <br /> * permitted in any medium without royalty provided this notice <br /> * is preserved. <br /> * <br /> */<br /> <br /> import org.owasp.jbrofuzz.core.NoSuchFuzzerException;<br /> import org.owasp.jbrofuzz.core.Database;<br /> import org.owasp.jbrofuzz.core.Fuzzer; <br /> <br /> /**<br /> * &amp;lt;p&amp;gt;Example iterating through all the methods available<br /> * in the Fuzzer Object and their respective outputs.&amp;lt;/p&amp;gt;<br /> *<br /> * @author subere@uncon.org<br /> * @version n/a<br /> */<br /> public class IndigoFuzzerTests {<br /> <br /> /**<br /> * @param args<br /> */<br /> public static void main(String[] args) {<br /> <br /> // You have to construct an instance of the fuzzers database<br /> Database fuzzDB = new Database();<br /> // You have to supply a valid fuzzer ID<br /> String f_ID = &quot;033-B08-OCT&quot;;<br /> // You have to supply a (+)tive int<br /> int f_len = 5;<br /> <br /> try {<br /> <br /> Fuzzer f = fuzzDB.createFuzzer(f_ID, f_len);<br /> <br /> while(f.hasNext()) {<br /> <br /> // Could do this via reflection, but..<br /> f.next();<br /> // System.out.println(&quot; The fuzzer payload is: &quot; + f.next());<br /> System.out.println(&quot; The maximum value is: &quot; + f.getMaximumValue());<br /> <br /> System.out.println(&quot; The current value is: &quot; + f.getCurrectValue());<br /> <br /> <br /> <br /> }<br /> <br /> <br /> } catch (NoSuchFuzzerException e) {<br /> <br /> System.out.println(&quot;Could not find fuzzer &quot; + e.getMessage());<br /> <br /> }<br /> <br /> }<br /> <br /> }<br /> &lt;/pre&gt; <br /> === Advanced Fuzzing with the JBroFuzz Library ===<br /> <br /> This section covers more advanced APIs that are available under the '''org.owasp.jbrofuzz.core package'''. It should be noted that some of these classes and their corresponding functionality are not used by the JBroFuzz program application. Instead, they are made available for incorporation into other java code that you have perhaps written that requires more specialized type of fuzzing. <br /> <br /> ==== Fuzzing Really Long Values with Big Integer ====<br /> <br /> As stated previously, within JBroFuzz a Fuzzer is a java Iterator. This implies that while fuzzing, we typically keep track of a counter representing the value that we are currently on. Consider the example of HelloFuzzer.java, above: <br /> &lt;pre&gt;import org.owasp.jbrofuzz.core.*;<br /> <br /> public class HelloFuzzer {<br /> <br /> public static void main(String[] args) {<br /> <br /> Database fuzzDB = new Database();<br /> <br /> try {<br /> for(Fuzzer f = fuzzDB.createFuzzer(&quot;031-B16-HEX&quot;, 4); f.hasNext();) {<br /> // Get the next payload value...<br /> System.out.println(&quot; The fuzzer payload is: &quot; + f.next());<br /> }<br /> } catch (NoSuchFuzzerException e) {<br /> System.out.println(&quot;Could not find fuzzer &quot; + e.getMessage());<br /> }<br /> <br /> }<br /> <br /> } // HelloFuzzer.java OWASP JBroFuzz Example 1<br /> &lt;/pre&gt; <br /> If we compile this program: <br /> &lt;pre&gt;javac -classpath &quot;.\jbrofuzz\jar\JBroFuzz.jar&quot; HelloFuzzer.java<br /> &lt;/pre&gt; <br /> and run it: <br /> &lt;pre&gt;java -cp &quot;.\jbrofuzz\jar\JBroFuzz.jar;.&quot; HelloFuzzer<br /> &lt;/pre&gt; <br /> We are going to see output similar to: <br /> &lt;pre&gt; The fuzzer payload is: 0000<br /> ... (output omitted)<br /> The fuzzer payload is: fffd<br /> The fuzzer payload is: fffe<br /> The fuzzer payload is: ffff<br /> &lt;/pre&gt; <br /> Now what if we want a hexadecimal fuzzer of length not 4, but, say, 24. Let's try compile and run the above program with a length of 24. Changing the line to: <br /> &lt;pre&gt; for(Fuzzer f = fuzzDB.createFuzzer(&quot;031-B16-HEX&quot;, 24); f.hasNext();) {<br /> &lt;/pre&gt; <br /> Running this modified version of HelloFuzzer.java, yields: <br /> &lt;pre&gt;&amp;gt;javac -classpath &quot;.\jbrofuzz\jar\JBroFuzz.jar;.&quot; HelloFuzzer.java<br /> <br /> &amp;gt;java -classpath &quot;.\jbrofuzz\jar\JBroFuzz.jar;.&quot; HelloFuzzer<br /> <br /> &amp;gt;<br /> &lt;/pre&gt; <br /> Nothing! What is actually happening is JBroFuzz is figuring out that the specified length of the Fuzzer we are about to create is far greater than that of the long java data type. As a result, the Fuzzer is not even entering the iteration mode that is typically expected with methods next() and hasNext(). <br /> <br /> That's all great, but we still want a hexadecimal fuzzer, 24 digits long going from: <br /> &lt;pre&gt;000000000000000000000000<br /> ...to...<br /> ffffffffffffffffffffffff<br /> &lt;/pre&gt; <br /> For this JBroFuzz offers another type of Fuzzer class, that of FuzzerBigInteger. Let's modify the critical line within the original HelloFuzzer.java program that we had: <br /> &lt;pre&gt; for(FuzzerBigInteger f = fuzzDB.createFuzzerBigInteger(&quot;031-B16-HEX&quot;, 24); f.hasNext();) {<br /> &lt;/pre&gt; <br /> With the entire program becoming: <br /> &lt;pre&gt;import org.owasp.jbrofuzz.core.*;<br /> <br /> public class HelloFuzzer {<br /> <br /> public static void main(String[] args) {<br /> <br /> Database fuzzDB = new Database();<br /> <br /> try {<br /> for(FuzzerBigInteger f = fuzzDB.createFuzzerBigInteger(&quot;031-B16-HEX&quot;, 24); f.hasNext();) {<br /> // Get the next payload value...<br /> System.out.println(&quot; The fuzzer payload is: &quot; + f.next());<br /> }<br /> } catch (NoSuchFuzzerException e) {<br /> System.out.println(&quot;Could not find fuzzer &quot; + e.getMessage());<br /> }<br /> <br /> }<br /> <br /> } // HelloFuzzer.java OWASP JBroFuzz Example 1<br /> &lt;/pre&gt; <br /> Compiling and running this program yields: <br /> &lt;pre&gt; The fuzzer payload is: 000000000000000000000000<br /> The fuzzer payload is: 000000000000000000000001<br /> ... (output omitted)<br /> The fuzzer payload is: 00000000000000000001a982<br /> ... (output omitted)<br /> The fuzzer payload is: 00000000000000000001a982<br /> The fuzzer payload is: ffffffffffffffffffffffff<br /> &lt;/pre&gt; <br /> There are limitations to this class, as governed by the BigInteger class itself. Further information can be found at: <br /> &lt;pre&gt;http://java.sun.com/j2se/1.5.0/docs/api/java/math/BigInteger.html<br /> &lt;/pre&gt; <br /> Still, on a virtual windows xp machine with 256Mb of RAM the above code had no problem running to completion. It took some time though.. Characteristics of the windows machine while this iteration was ongoing: The CPU was being utilised at 100% and memory usage was constant at 212 Mb. Overall, a clean sheet for FuzzerBigInteger.java. <br /> <br /> ==== Using the Power Fuzzer API ====<br /> <br /> With web applications, it is often that you find yourself re-using part of, or the entirety of a fuzzing payload in more than one location, as part of the GET, POST, or any other type of request you submit. <br /> <br /> For this reason, JBroFuzz offers the PowerFuzzer class: A type of iterator for which you can specify how many copies of the payload you require in each request. <br /> <br /> Let's consider the following trivial scenario. You are in need of all hexadecimal values, which are 4-digits long (i.e. 0000 to FFFF) and you are in need of these 5 times for each request. <br /> <br /> This scenario is trivial, because typically you can assign the fuzzing payload (i.e. the value you get back from Fuzzer.next() ) to a String variable and re-use it as many times as you see fit. <br /> &lt;pre&gt; Database fuzzDB = new Database();<br /> <br /> String fuzzerID = &quot;031-B16-HEX&quot;;<br /> int length = 4;<br /> ....<br /> for(Fuzzer f = fuzzDB.createFuzzer(fuzzerID, length); f.hasNext();) {<br /> String payload = f.next();<br /> ....<br /> }<br /> &lt;/pre&gt; <br /> Using the PowerFuzzer.class, the following HelloPowerFuzzer.java program can be created: <br /> &lt;pre&gt;import org.owasp.jbrofuzz.core.*;<br /> <br /> public class HelloPowerFuzzer {<br /> <br /> public static void main(String[] args) {<br /> <br /> Database fuzzDB = new Database();<br /> <br /> String fuzzerID = &quot;031-B16-HEX&quot;;<br /> int length = 4;<br /> int power = 5;<br /> <br /> try {<br /> for(PowerFuzzer f = fuzzDB.createPowerFuzzer(fuzzerID, length, power); f.hasNext();) {<br /> // Get the next payload in an array of length[power]<br /> String [] identicalElements = f.nextPower();<br /> <br /> // f.getPower() == identicalElements.length, always<br /> System.out.print(&quot; I have &quot; + f.getPower() + &quot; elements: &quot;);<br /> <br /> for(String elem&amp;nbsp;: identicalElements) {<br /> <br /> System.out.print(elem + &quot; &quot;);<br /> }<br /> System.out.println(&quot;&quot;);<br /> <br /> }<br /> } catch (NoSuchFuzzerException e) {<br /> System.out.println(&quot;Could not find fuzzer &quot; + e.getMessage());<br /> }<br /> <br /> }<br /> <br /> } // HelloPowerFuzzer.java OWASP JBroFuzz Power Fuzzer Example<br /> <br /> &lt;/pre&gt; <br /> This program would output the following; no rocket science here: <br /> &lt;pre&gt;....<br /> I have 5 elements: 4817 4817 4817 4817 4817<br /> I have 5 elements: 4818 4818 4818 4818 4818<br /> I have 5 elements: 4819 4819 4819 4819 4819<br /> I have 5 elements: 481a 481a 481a 481a 481a<br /> I have 5 elements: 481b 481b 481b 481b 481b<br /> I have 5 elements: 481c 481c 481c 481c 481c<br /> I have 5 elements: 481d 481d 481d 481d 481d<br /> I have 5 elements: 481e 481e 481e 481e 481e<br /> I have 5 elements: 481f 481f 481f 481f 481f<br /> I have 5 elements: 4820 4820 4820 4820 4820<br /> I have 5 elements: 4821 4821 4821 4821 4821<br /> I have 5 elements: 4822 4822 4822 4822 4822<br /> I have 5 elements: 4823 4823 4823 4823 4823<br /> I have 5 elements: 4824 4824 4824 4824 4824<br /> I have 5 elements: 4825 4825 4825 4825 4825<br /> I have 5 elements: 4826 4826 4826 4826 4826<br /> ....<br /> &lt;/pre&gt; <br /> Now imagine you need to change the number of elements you obtain back every time. For every second request, you need to obtain back two identical payloads, for every third request, you need to obtain back three payloads and for every fourth request, you need to obtain back four payloads. <br /> <br /> The PowerFuzzer class, with the corresponding method '''setPower(int)''' allows you to set how many identical elements you obtain back, without having to worry about the length argument. Below is a class that solves the above scenario: <br /> &lt;pre&gt;import org.owasp.jbrofuzz.core.*;<br /> <br /> public class HelloPowerFuzzer {<br /> <br /> public static void main(String[] args) {<br /> <br /> Database fuzzDB = new Database();<br /> <br /> String fuzzerID = &quot;031-B16-HEX&quot;;<br /> int length = 4;<br /> int power = 5;<br /> <br /> try {<br /> for(PowerFuzzer f = fuzzDB.createPowerFuzzer(fuzzerID, length, power); f.hasNext();) {<br /> <br /> int currentValue = (int) f.getCurrentValue(); <br /> currentValue&amp;nbsp;%= 4;<br /> switch (currentValue) {<br /> case 0: f.setPower(1); break;<br /> case 1: f.setPower(2); break;<br /> case 2: f.setPower(3); break;<br /> default: f.setPower(4); break;<br /> }<br /> <br /> // Get the next payload in an array of length[power]<br /> String [] identicalElements = f.nextPower();<br /> <br /> // f.getPower() == identicalElements.length, always<br /> System.out.print(&quot; I have &quot; + f.getPower() + &quot; elements: &quot;);<br /> // System.out.println(currentValue);<br /> <br /> for(String elem&amp;nbsp;: identicalElements) {<br /> <br /> System.out.print(elem + &quot; &quot;);<br /> }<br /> System.out.println(&quot;&quot;);<br /> <br /> }<br /> } catch (NoSuchFuzzerException e) {<br /> System.out.println(&quot;Could not find fuzzer &quot; + e.getMessage());<br /> }<br /> <br /> }<br /> <br /> } // HelloPowerFuzzer.java<br /> <br /> &lt;/pre&gt; <br /> This class has as output: <br /> &lt;pre&gt; ....<br /> I have 1 elements: 22a8<br /> I have 2 elements: 22a9 22a9<br /> I have 3 elements: 22aa 22aa 22aa<br /> I have 4 elements: 22ab 22ab 22ab 22ab<br /> I have 1 elements: 22ac<br /> I have 2 elements: 22ad 22ad<br /> I have 3 elements: 22ae 22ae 22ae<br /> I have 4 elements: 22af 22af 22af 22af<br /> I have 1 elements: 22b0<br /> I have 2 elements: 22b1 22b1<br /> I have 3 elements: 22b2 22b2 22b2<br /> I have 4 elements: 22b3 22b3 22b3 22b3<br /> I have 1 elements: 22b4<br /> I have 2 elements: 22b5 22b5<br /> I have 3 elements: 22b6 22b6 22b6<br /> I have 4 elements: 22b7 22b7 22b7 22b7<br /> I have 1 elements: 22b8<br /> I have 2 elements: 22b9 22b9<br /> ....<br /> &lt;/pre&gt; <br /> Naturally, the algorithm of the number of elements required can vary based on any number of parameters. The PowerFuzzer class gives you a quick way to control the number of identical payloads you obtain back, without having to worry about creating a data type to store them in. <br /> <br /> ==== Using the Double Fuzzer API ====<br /> <br /> In some cases of fuzzing web applications, a requirement to fuzz two (or more) locations part of the request being submitted to the web server becomes apparent. <br /> <br /> The DoubleFuzzer class allows you to create a fuzzer based on two prototype definitions. Similarly to instantiating a Fuzzer through a prototype and a given length, with a DoubleFuzzer, we pass two prototype definitions and two lengths. The corresponding method call available within the '''Database''' class of org.owasp.jbrofuzz.core is: <br /> &lt;pre&gt;public DoubleFuzzer createDoubleFuzzer(String id1, int length1, <br /> String id2, int length2) throws NoSuchFuzzerException {<br /> &lt;/pre&gt; <br /> Let's cross-breed some fuzzers, see what results we get back during an iteration. <br /> <br /> The first example below, uses two hexadecimal fuzzers of different lengths, as specified by the variables: <br /> &lt;pre&gt;String fuzzID1 = &quot;031-B16-HEX&quot;;<br /> String fuzzID2 = &quot;031-B16-HEX&quot;;<br /> <br /> int length1 = 4;<br /> int length2 = 2;<br /> &lt;/pre&gt; <br /> As the double fuzzer iteration is taking place, the second fuzzer, defined by the fuzzID2 &amp;amp; length2 loops, starting from 00 and going all the way up to FF. An example output is: <br /> &lt;pre&gt; I have 2 elements: fefb fb<br /> I have 2 elements: fefc fc<br /> I have 2 elements: fefd fd<br /> I have 2 elements: fefe fe<br /> I have 2 elements: feff ff<br /> I have 2 elements: ff00 00<br /> I have 2 elements: ff01 01<br /> I have 2 elements: ff02 02<br /> I have 2 elements: ff03 03<br /> &lt;/pre&gt; <br /> The complete code listing of HelloDoubleFuzzer.java is: <br /> &lt;pre&gt;import org.owasp.jbrofuzz.core.*;<br /> <br /> public class HelloDoubleFuzzer {<br /> <br /> public static void main(String[] args) {<br /> <br /> Database fuzzDB = new Database();<br /> <br /> String fuzzID1 = &quot;031-B16-HEX&quot;;<br /> String fuzzID2 = &quot;031-B16-HEX&quot;;<br /> <br /> int length1 = 4;<br /> int length2 = 2;<br /> <br /> try {<br /> DoubleFuzzer f = fuzzDB.createDoubleFuzzer(fuzzID1, length1, fuzzID2, length2);<br /> <br /> while( f.hasNext() ) {<br /> // Get the next payload in an array of length[power]<br /> String [] payloads = f.next();<br /> <br /> // f.getPower() == identicalElements.length, always<br /> System.out.print(&quot; I have &quot; + f.getPower() + &quot; elements: &quot;);<br /> // System.out.println(currentValue);<br /> <br /> for(String elem&amp;nbsp;: payloads) {<br /> <br /> System.out.print(elem + &quot; &quot;);<br /> }<br /> System.out.println(&quot;&quot;);<br /> <br /> }<br /> } catch (NoSuchFuzzerException e) {<br /> System.out.println(&quot;Could not find fuzzer &quot; + e.getMessage());<br /> }<br /> <br /> }<br /> <br /> } // HelloDoubleFuzzer.java<br /> &lt;/pre&gt; <br /> That's simple enough; now let's cross-breed something a bit more exotic: Imagine a 3-digit octal ID value [000 - 777] being submitted inline with, say, a parameter that we want to test for Cross-Site Scripting (XSS). Let's adjust the program above with the corresponding fuzzer IDs of these fuzzers. Remember all the IDs of all the fuzzers can be found in the fuzzers.jbrf file within JBroFuzz.jar: <br /> &lt;pre&gt;import org.owasp.jbrofuzz.core.*;<br /> <br /> public class HelloDoubleFuzzer {<br /> <br /> public static void main(String[] args) {<br /> <br /> Database fuzzDB = new Database();<br /> <br /> String fuzzID1 = &quot;033-B08-OCT&quot;;<br /> String fuzzID2 = &quot;019-XSS-GEK&quot;;<br /> <br /> int length1 = 3;<br /> int length2 = 1;<br /> <br /> try {<br /> DoubleFuzzer f = fuzzDB.createDoubleFuzzer(fuzzID1, length1, fuzzID2, length2);<br /> <br /> while( f.hasNext() ) {<br /> // Get the next payload in an array of length[power]<br /> String [] payloads = f.next();<br /> <br /> // f.getPower() == identicalElements.length, always<br /> System.out.print(&quot; I have &quot; + f.getPower() + &quot; elements: &quot;);<br /> // System.out.println(currentValue);<br /> <br /> for(String elem&amp;nbsp;: payloads) {<br /> <br /> System.out.print(elem + &quot; &quot;);<br /> }<br /> System.out.println(&quot;&quot;);<br /> <br /> }<br /> } catch (NoSuchFuzzerException e) {<br /> System.out.println(&quot;Could not find fuzzer &quot; + e.getMessage());<br /> }<br /> <br /> }<br /> <br /> } // HelloDoubleFuzzer.java<br /> &lt;/pre&gt; <br /> The output from this program is: <br /> &lt;pre&gt; I have 2 elements: 000 (1?(1?{a:1?&quot;&quot;[1?&quot;ev\a\l&quot;:0](1?&quot;\a\lert&quot;:0):0}:0).a:0)[1?&quot;\c\a\l\l&quot;:0](content,1?&quot;x\s\s&quot;:0)<br /> I have 2 elements: 001 &amp;lt;STYLE TYPE=&quot;text/javascript&quot;&amp;gt;alert('XSS');&amp;lt;/STYLE&amp;gt;<br /> I have 2 elements: 002 &amp;lt;SCRIPT SRC=http://ha.ckers.org/xss.js<br /> I have 2 elements: 003 &amp;lt;A HREF=&quot;http://google:ha.ckers.org&quot;&amp;gt;XSS&amp;lt;/A&amp;gt;<br /> I have 2 elements: 004 &amp;lt;A HREF=&quot;http://ha.ckers.org@google&quot;&amp;gt;XSS&amp;lt;/A&amp;gt;<br /> I have 2 elements: 005 &amp;lt;A HREF=&quot;//google&quot;&amp;gt;XSS&amp;lt;/A&amp;gt;<br /> ....<br /> ...<br /> ..<br /> .<br /> ..<br /> ...<br /> ....<br /> I have 2 elements: 774 &amp;lt;SCRIPT SRC=http://ha.ckers.org/xss.js<br /> I have 2 elements: 775 &amp;lt;A HREF=&quot;http://google:ha.ckers.org&quot;&amp;gt;XSS&amp;lt;/A&amp;gt;<br /> I have 2 elements: 776 &amp;lt;A HREF=&quot;http://ha.ckers.org@google&quot;&amp;gt;XSS&amp;lt;/A&amp;gt;<br /> I have 2 elements: 777 &amp;lt;A HREF=&quot;//google&quot;&amp;gt;XSS&amp;lt;/A&amp;gt;<br /> &lt;/pre&gt; <br /> With the list stopping iterating at the last element of the greatest of the two fuzzers. <br /> <br /> ==== Using the Cross Product Fuzzer API ====<br /> <br /> A final case of a special Double Fuzzer is the the Cross Product Fuzzer of the payloads of two fuzzers. This type of fuzzing is virtually encountered in username/password login form on the Internet. Let's work on this by example. <br /> <br /> Consider your home network router. You recall changing the default password to one of the typical password values that you use. Also, you are not 100% certain about the username for the router either, it is one of the typical admin, user, administrator, root, yoda type values, but you cannot recall which one. Needless to say, you don't know what the username, or password actually is. <br /> <br /> So in a mini brute-forcing attack scenario, you have the following list of usernames, out of which one is valid: <br /> &lt;pre&gt;admin<br /> administrator<br /> Administrator<br /> root<br /> adminUser<br /> &lt;/pre&gt; <br /> Also you know that the password is one of the following (Top 10 Threadwatch 2007 passwords): <br /> &lt;pre&gt;password<br /> 123456<br /> qwerty<br /> abc123<br /> letmein<br /> monkey<br /> myspace1<br /> password1<br /> blink182<br /> &lt;/pre&gt; <br /> The set that contains every possible combination of the two sets is the Cross Product of the list of usernames, times the list of passwords. So manually, (as most people do while locking themselves out) you would try, popular combinations of the above, starting with: <br /> &lt;pre&gt;admin password<br /> admin 123456<br /> admin qwerty<br /> ....<br /> admin blink182<br /> administrator password<br /> administrator 123456<br /> administrator qwerty<br /> ....<br /> adminUser password1<br /> adminUser blink182<br /> &lt;/pre&gt; <br /> Thus the total number of attempts would be (number of usernames) x (number of passwords). No rocket science here. <br /> <br /> JBroFuzz introduces the CrossProductFuzzer class capable of iterating through the cross product of two fuzzers. Let's put it into code; the following program provides a list of all 2-digit octal numbers with every 2-digit binary number. A total of (8 x 8) x (2 x 2) = 256 values. <br /> &lt;pre&gt;import org.owasp.jbrofuzz.core.*;<br /> <br /> public class HelloCrossFuzzer {<br /> <br /> public static void main(String[] args) {<br /> <br /> Database fuzzDB = new Database();<br /> <br /> String fuzzID1 = &quot;033-B08-OCT&quot;;<br /> String fuzzID2 = &quot;034-B02-BIN&quot;;<br /> <br /> int length1 = 2;<br /> int length2 = 2;<br /> <br /> try {<br /> CrossProductFuzzer f = fuzzDB.createCrossFuzzer(fuzzID1, length1, fuzzID2, length2);<br /> <br /> while( f.hasNext() ) {<br /> // Get the next payload in an array of length[power]<br /> String [] payloads = f.next();<br /> <br /> // f.getPower() == identicalElements.length, always<br /> System.out.print(&quot; I have &quot; + f.getPower() + &quot; elements: &quot;);<br /> // System.out.println(currentValue);<br /> <br /> for(String elem&amp;nbsp;: payloads) {<br /> <br /> System.out.print(elem + &quot; &quot;);<br /> }<br /> System.out.println(&quot;&quot;);<br /> <br /> }<br /> } catch (NoSuchFuzzerException e) {<br /> System.out.println(&quot;Could not find fuzzer &quot; + e.getMessage());<br /> }<br /> <br /> }<br /> <br /> } // HelloCrossFuzzer.java<br /> &lt;/pre&gt; <br /> This program has as output: <br /> &lt;pre&gt; I have 2 elements: 00 00<br /> ...<br /> ..<br /> .<br /> ..<br /> ...<br /> I have 2 elements: 74 00<br /> I have 2 elements: 74 01<br /> I have 2 elements: 74 10<br /> I have 2 elements: 74 11<br /> I have 2 elements: 75 00<br /> I have 2 elements: 75 01<br /> I have 2 elements: 75 10<br /> I have 2 elements: 75 11<br /> I have 2 elements: 76 00<br /> I have 2 elements: 76 01<br /> I have 2 elements: 76 10<br /> I have 2 elements: 76 11<br /> I have 2 elements: 77 00<br /> I have 2 elements: 77 01<br /> I have 2 elements: 77 10<br /> I have 2 elements: 77 11<br /> &lt;/pre&gt; <br /> You can substitute any list of fuzzer ID to the IDs you use in this program. <br /> <br /> '''Remember!''' The total number of payloads must not exceed that of the the maximum value of the long primitive java data type ''Long.MAX_VALUE'' which is 2^63 - 1. If you are in need of more than that payloads, you would have to use the big integer implementation of the Fuzzer class, namely: FuzzerBigInteger.java. <br /> <br /> == Graphing with JBroFuzz ==<br /> <br /> Once a fuzzing session has completed, JBroFuzz offers the ability to generate a number of graphs, using various metrics. This section investigates how to further the graphing functionality available with the application. <br /> <br /> === Customizing the logo on each Graph ===<br /> <br /> As of version 2.0, all image icons within JBroFuzz are located within the /icons directory of the application. The particular transparent image file displayed on top right part of the graphs is named: <br /> &lt;pre&gt;/icons/owasp-med.png<br /> &lt;/pre&gt; <br /> This file is a 64 x 64 PNG image file. You can replace it with your own file, as follows: <br /> &lt;pre&gt;&amp;gt;ls -l JBroFuzz.jar<br /> -rw-rw-rw- 1 user group 4033612 Feb 15 12:33 JBroFuzz.jar<br /> <br /> &amp;gt;unzip -oq JBroFuzz.jar<br /> &amp;gt;cd icons<br /> &amp;gt;mv owasp-med.png file64x64-file.png<br /> &amp;gt;cd ..<br /> &amp;gt;zip -r JBroFuzz.zip *<br /> &amp;gt;mv JBroFuzz.zip JBroFuzz.jar<br /> &lt;/pre&gt; <br /> This enables you to have your own (company logo) on JBroFuzz graphs. Further to this, a number of other customization options are available, by right clicking on each of the graph generated. <br /> <br /> [[Category:OWASP_JBroFuzz]]</div>

Jorge Correa https://wiki.owasp.org/index.php?title=Category:OWASP_Enterprise_Security_API/es&diff=81079 2010-04-07T15:12:08Z

<p>Jorge Correa: /* Proyecto OWASP API de seguridad empresarial (ESAPI) */</p> <hr /> <div>=Proyecto OWASP API de seguridad empresarial (ESAPI) =<br /> <br /> La ESAPI es una colección gratis y abierta de todos los métodos de seguridad que un desarrollador necesita para construir una aplicación Web segura. Usted puede usar solo las interfases y construir su propia implementación usando la infraestructura de su compañía. O, puede user la implementación de referencia como un punto de inicio. En concepto, la API es independiente del lenguaje. Sin embargo, los primeros entregables del proyecto son una API Java y una referencia de implementación Java. Esfuerzos para construir ESAPI en .NET y PHP están en marcha.<br /> <br /> Desafortunadamente, las plataformas disponibles, y herramientas (Java EE, Struts, Spring, etc...) simplemente no proporcionan protección suficiente. Esto deja a los desarrolladores con la responsabilidad de diseñar y construir mecanismos de seguridad. Este reinventado de la rueda para cada aplicación lleva a una perdida de tiempo y agujeros de seguridad masivos.<br /> <br /> Los ahorros de costos a través de tiempos de desarrollo reducidos, y la seguridad incrementada debido al uso de métodos de seguridad fuertemente analizados y cuidadosamente diseñados proporcionan a los desarrolladores con ventajas masivas sobre organizaciones que están tratando de lidiar con la seguridad usando técnicas seguras de programación para este propósito. Esta API esta diseñada para hacerse cargo automáticamente de muchos aspectos de la seguridad en aplicaciones, haciendo estos problemas invisibles para los desarrolladores.<br /> <br /> El proyecto OWASP ESAPI es dirigido por [[User:Jeff Williams|Jeff Williams]], quien sirve como presidente de voluntariado de OWASP y es el CEO de Aspect Security. Jeff es un desarrollador de software que se ha especializado en seguridad de aplicaciones desde 1995. ESAPI es el resultado de mas de una década de revisión de código y pruebas de intrusión de aplicaciones empresariales criticas. Si desea ser voluntario para ayudar en el proyecto, puede contactarlo en jeff.williams@owasp.org.<br /> <br /> <br /> ==Descargar ahora==<br /> <br /> Esta versión es la primera versión publica e indudablemente se someterá a una revisión significativa en los próximos meses. Estamos buscando organizaciones dispuestas a usar ESAPI en un programa piloto y que trabajen con nosotros para hacer esta biblioteca mejor. Por favor contacte a jeff.williams@owasp.org para mas información. Si esta interesado en seguridad de aplicaciones, por favor únase a la[http://lists.owasp.org/mailman/listinfo/owasp-esapi lista de correos de OWASP ESAPI] y ayude a hacer ESAPI mejor!<br /> <br /> * [http://code.google.com/p/owasp-esapi-java/ Repositorio de código]<br /> * [http://code.google.com/p/owasp-esapi-java/issues/list Reportar problemas]<br /> <br /> Ultima versión (versiones anteriores están publicadas en el repositorio de código)<br /> <br /> * [http://owasp-esapi-java.googlecode.com/files/owasp-esapi-java-1.1.1.jar ESAPI v1.1.1 Complete JAR file] (Java 1.4 compatible)<br /> * [http://owasp-esapi-java.googlecode.com/files/owasp-esapi-java-src-1.1.1.zip ESAPI v1.1.1 Source archive]<br /> <br /> Primeros pasos<br /> <br /> * [http://owasp-esapi-java.googlecode.com/svn/trunk/javadoc/index.html Javadoc en línea]<br /> * [http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/OWASP%20ESAPI%20Overview.pptx Presentación PowerPoint de ESAPI]<br /> <br /> ==Arquitectura==<br /> <br /> La arquitectura de ESAPI es muy simple, es solo una colección de clases que encapsula las operaciones clave de seguridad que la mayoría de las aplicaciones necesitan. ESAPI esta diseñado para hacer fácil el ajustar la seguridad en aplicaciones existentes, así como proporcionar una base sólida para un nuevo desarrollo. Nuevos proyectos de desarrollo deberían considerar integrar ESAPI en su framework para hacer que la seguridad ocurra automáticamente. ESAPI viene con un filtro ESAPI que minimiza los cambios requeridos en su aplicación base.<br /> <br /> https://www.owasp.org/images/7/71/OWASP_ESAPI_Architecture_es.png<br /> <br /> ESAPI cubre la mayoría de los retos de seguridad que enfrentan los desarrolladores. ESAPI provee la capacidad a los desarrolladores para crear aplicaciones que están protegidas en contra de casi todos los riesgos descritos en el OWASP [[Top Ten]]. Compare esta cobertura con escaneo automático y herramientas de análisis estático, y entonces considere como es mejor empleado su tiempo. <br /> <br /> https://www.owasp.org/images/4/48/OWASP_ESAPI_Top_Ten_es.png<br /> <br /> Hay dos partes clave en ESAPI:<br /> * Un conjunto de interfaces <br /> * Una implementación de referencia <br /> <br /> Usando ESAPI, las aplicaciones a lo largo de una organización serán mas fáciles de desarrollar, mas consistentes, y mas fáciles de actualizar en un solo lugar. El uso de ESAPI hará mucho mas fácil para las herramientas de análisis estático verificar una aplicación, como las llamadas a ESAPI pueden ser construidas en el conjunto de reglas.<br /> <br /> ==Patrocinadores del proyecto== <br /> <br /> El proyecto OWASP ESAPI es patrocinado por <br /> [http://www.aspectsecurity.com https://www.owasp.org/images/d/d1/Aspect_logo.gif]<br /> <br /> ==Licenciamiento==<br /> Este proyecto tiene doble licenciamiento bajo GPL and BSD. Elija cualquiera que se ajuste a su política corporativa...[JFM]<br /> <br /> [[Category:OWASP Download]]<br /> [[Category:OWASP Project|Enterprise Security API/es]]<br /> __NOTOC__</div>

Jorge Correa https://wiki.owasp.org/index.php?title=Anexo_para_Contrato_de_Software_Seguro_de_OWASP&diff=79870 2010-03-12T21:29:12Z

<p>Jorge Correa: /* SOBRE EL PROYECTO */</p> <hr /> <div>'''ANEXO DE CONTRATO PARA DESAROLLO DE SOFTWARE SEGURO'''<br /> <br /> ADVERTENCIA: ESTE DOCUMENTO DEBE SER CONSIDERADO COMO UNA GUÍA SOLAMENTE.<br /> OWASP RECOMIENDA VEHEMENTEMENTE QUE CONSULTE UN ABOGADO CALIFICADO<br /> PARA AYUDARLE A NEGOCIAR UN CONTRATO DE SOFTWARE<br /> <br /> == Introducción ==<br /> <br /> Este anexo de contrato pretende ayudar a los proveedores de software y sus clientes a negociar y capturar importantes términos y condiciones contractuales relacionadas a la seguridad en el Software a ser desarrollado o entregado. La razon para este proyecto es que la mayoría de los contratos no mencionan estos temas, y las partes frecuentamente tienen puntos de vista dramaticamente diferentes a lo que en ralidad fue acordado. Creemos que articular claramente estos términos es la mejor manera de asegurarse que ambas partes pueden hacer desiciones informadas sobre como proceder. <br /> <br /> &quot;La seguridad del software comercial mejorará cuando el mercado demande mejor seguridad.<br /> Al menos, cada petición para propuestas de software debería pedir a los vendedores <br /> detallar como van ellos a probar sus productos para encotrar vulnerabilidades de<br /> seguridad. Este paso empezará convenciendo a los vendedores de software empaquetado<br /> y proveedores externos que las compañias valoran la seguridad.&quot;<br /> <br /> -- John Pescatore, Director de investiagacion con Gartner&lt;br&gt; <br /> <br /> Pedimos a los clientes y proveedores que usen este documento como un marco para discutir<br /> espectativas y negociar responsabilidades. Este anexo se creó para ser añadido a un<br /> contrato de desarrollo de software. Estos términos son negociables, significa que ellos<br /> pueden y deben ser discutidos por el cliente y el proveedor.<br /> <br /> == SOBRE EL PROYECTO ==<br /> <br /> Este documento fue creado por la fundación OWASP (Open Web Application Security Project por sus siglas en Inglés), una organización sin animo de lucro con el objetivo de crear herramientas y documentación, gratuita y abierta para asegurar software. Para facilitar su uso en contratación privada, este documento es de dominio publico. Puede encontrar detalles adicionales sobre este proyecto en http://www.owasp.org/index.php/OWASP_Legal_Project. Son Bienvenidos comentarios de ambos, productores y consumidores de software, asi como de la comunidad legal. <br /> <br /> OWASP reconoce gratamente la contribución especial de [http://www.aspectsecurity.com Aspect Security] por su rol en la investigación y preparación de este documento.<br /> <br /> ==OBJECIONES==<br /> <br /> Las siguientes páginas cubren algunas objeciones que escuchamos frecuentemente sobre usar este lenguaje en contratos de desarrollo de software:<br /> <br /> === PERO NO TODOS LOS TÉRMINOS SON CORRECTOS PARA NOSOTROS… ===<br /> <br /> Este documento debe ser considerado un punto de inicio para su contrato. Puede que no le gusten todas las actividades, o puede querer proponer mas. Puede querer asignar responsabilidades de manera diferente. Este documento no pretende capturar exactamente las necesidades de todos los clientes y proveedores de software. Pretende proveer un marco para discutir temas clave, importantes para asegurarse que el software se cree de forma segura. Despues de que tengan una discusión sobre seguridad y alcancen un acuerdo. Puede ajustar el convenio para que concuerde con el contrato.<br /> <br /> === PERO, ¿QUIEN DEBE PAGAR POR ESTAS ACTIVIDADES?… ===<br /> <br /> Este contrato no es sobre poner mas peso al desarollo de software. La pregunta no es sobre si hay costos asociados con seguridad (por supuesto que hay). La pregunta correcta es qué actividades deberían hacerse por ambas partes para minimizar costos, y cuando deberían ocurrir. <br /> <br /> Este anexo no menciona (intensionalmente) sobre el detalle de quién debería pagar por la actividades descritas. Mientras muchas de estas actividades deben estar pasando ya, y son esperadas por muchos clientes, ellas no estan practicadas regularmente en la industria del software. La cuestion de quién paga (y cuándo) debe ser parte de la negociación. <br /> <br /> Calcular el costo de la seguridad es muy difícil. Auque hay costos asociados con realizar actividades de seguridad, hay también costos importantes asociados con ignorar estas actividades. Estamos convencidos el mejor costo-beneficio para desarrollar software es reducir la probabilidad de que fallas de seguridad sean introducidas y minimzar el tiempo entre introducir una falla y arreglarla. <br /> <br /> Una distición importante a hacer cuando calculamos costos es entre construir mecanismos de seguridad y las actividades para asegurarse que esos mecanismos sean correctos y efectivos. Intentar agregar mecanismoa al final de el ciclo de desarrollo puede causar serios problemas de diseño e incrementará el costo dramáticamente. Este convenio promueve decisiones sobre mecanismos para minimizar estos costos. Similarmente, esperar hasta justo antes de la puesta en producción para hacer actividades de aseguramiento, tales como revisión de código y pruebas de intrusión, tambien incrementaría los costos dramaticamente. Creemos que el mejor costo-beneficio para ganar certeza es poner un nivel constante de esfuerzo en el aseguramiento a través del ciclo de desarrollo.<br /> <br /> === PERO EL NIVEL DE RIGOR ESTA INCORRECTO…. ===<br /> <br /> Este convenio asume que el software que esta siendo desarrollado es razonablemente importante para una empresa grande o agencia de gobierno. Hemos seleccionado un &quot;nivel de rigor&quot; para el convenio que es alcanzable por la mayoria de las organizaciones proveedoras de software, e identificaría y manejaría los riesgos más comunes. <br /> <br /> Sin embargo, para el software que va a ser usado en aplicaciones críticas, como aplicaciones médicas, financieras o relacionadas con el ejército. Puede querer incrementar el nivel de rigor. Puede querer agregar revisiones, documentación y actividades adicionales de prueba. Puede querer mejorar el proceso de encontrar, diagnosticar y remediar vulnerabilidades. Para aplicaciones menos sensibles, puede desear reducir o remover actividades.<br /> <br /> === PERO NOSOTROS NO PODEMOS ACEPTAR TANTO RIESGO… ===<br /> <br /> Este convenio pretende facilitar la discusión sobre quién tomaría el riesgo por las vulnerabilidades de seguridad en el software. Por un lado del espectro, el cliente podría tomar todo el riesgo y el proveedor podría entregar código con muchas vulnerabilidades. Por el otro extremo, el proveedor podría tomar todo el riesgo y asumir la responsabilidad de entregar código perfecto. Ambos extremos son irrealizables. <br /> <br /> Actualmente, en este convenio, el proveedor toma el riesgo por problemas que sean descubiertos en los requerimientos o deben ser cubiertos por esfuerzos razonables en pruebas. Pero la remediación de &quot;nuevos&quot; problemas de seguridad tendría que ser pagado por el cliente. Creemos que este es un equilibrio funcional, ya que limita el riesgo adquirido por el proveedor y promueve obtener requerimientos de seguridad por anticipado. Pero hay muchas otras posibles soluciones a este problema. Por favor, dejenos saber si tiene sugerencias alternas, podriamos incluirlas en versiones futuras de este documento. <br /> <br /> Note que la discusión aqui solo cubre el riesgo asociado con arreglar las vulnerabilidades de seguridad en el código, y no incluye los costos asociados con recuperarse de incidentes de seguridad relacionados con explotar cualquiera de esas vulnerabilidades. Estamos interesados en las mejores prácticas en esta area.<br /> <br /> === PERO COMO PODEMOS ASEGURAR CÓDIGO DE TERCEROS… ===<br /> <br /> Casi todos los proyectos de sofware tienen una cantidad importante de código de terceros como librerias, frameworks y productos. Desde la perspectiva de seguridad, este código es tan importante como el código desarrollado a la medida para su proyecto. Creemos que la responsabilidad de garantizar la seguridad de este código es llevada mejor por el proveedor, aunque ellos podrían no tener toda la capacidad para garantizar la seguridad por ellos mismos. Sin embargo, la seguridad puede ser parte de el la desición de &quot;construir o comprar&quot;, y esta parece ser la mejor manera de promoverla. <br /> <br /> El proveedor, por supuesto, tiene la opción de pasar la responsabilidad al proveedor del software de terceros. El desarrollador puede también analizar el código de terceros por él mismo o contratar expertos en seguridad para analizarlo por él.<br /> <br /> === PERO PORQUE DEBO PASAR POR TODO ESTE PROBLEMA… ===<br /> <br /> En última instancia, creemos que no hay alternativa para hacer de la seguridad una parte de el proceso de contratación de software. Actualmente, creemos que hay serios malentendidos sobre la seguridad del código que esta siendo desarrollado bajo muchos contratos de desarrollo de software. Esto puede solamente llevar a una cara litigación y a desiciones hechas por individuos con poca experiencia y entendimiento sobre software. Lea el [[Secure software contracting hypothetical case study|Caso de estudio hipotético sobre contratación de software seguro]] para una discusión completa de este problema. <br /> <br /> Hay muchos beneficios al trabajar con este convenio. El principal es que pondrá claras las expectativas entre las partes involucradas. En algunos casos ayudará a evitar demandas cuando problemas de seguridad difíciles aparecen en el software. Tambien, estas son las mismas actividades requeridas por muchas razónes legales y de conformidad con estándares/leyes.<br /> <br /> === PERO ES MUY DIFÍCIL PRODUCIR TODA ESTA DOCUMENTACIÓN… ===<br /> <br /> OWASP no promueve la documentación por la simpre documentación. Este convenio está enfocado en promover la calidad, no la cantidad. Creemos que puede ser posible (en algunos proyectos) cumplir con este contrato con una pequeña evaluación de riesgo, algunas páginas de requerimientos, un pequeño documento de diseño de seguridad, un plan de pruebas, y algunos resultados de pruebas. <br /> <br /> El objetivo de esta documentación es simplemente asegurar, en cada etapa del desarrollo de software, que se ha puesto la atención apropiada en la seguridad. Un beneficio adicional es que esta documentación puede ser recolectada en conjunto para formar un &quot;paquete de certificación&quot; que básicamente esboce el argumento de porque deberiamos confiar que el software hará lo que dice.<br /> <br /> ==ANEXO DE CONTRATO==<br /> <br /> ===1. INTRODUCCIÓN===<br /> <br /> Esta anexo esta hecho para _____________________ (&quot;convenio&quot;) entre el Cliente y el proveedor. Tanto el Cliente como el proveedor acuerdan maximisar la seguridad del software de acuerdo a los siguientes términos.<br /> <br /> <br /> ===2. FILOSOFÍA===<br /> <br /> Esta anexo pretende aclarar los derechos y obligaciones relacionados a seguridad de todas las partes en una relacion de desarrollo de software. Al mayor nivel, las partes acuerdan que:<br /> <br /> ;(a) Las desiciones de seguridad estarán basadas en el riesgo : Las desciciones sobre la seguridad seran tomadas en conunto por el cliente y el proveedor basandose en un firme entendimiento de el riesgo involucrado. <br /> <br /> ;(b) Las actividades de seguridad estarán balanceadas : El esfurzo de seguridad será distribuido equitativamente a través de todo el ciclo de desarollo de software.<br /> <br /> ;(c) Las actividades de seguridad estarán integradas : Todas las actividades y documentación discutidas aqui pueden y deben ser integradas dentro del ciclo de desarrollo de software del proveedor y no mantenerse separadas de el resto del proyecto. Nada en este anexo implica algún processo de desarrollo de software en particular.<br /> <br /> ;(d) Se esperan vulnerabilidades : Todo software contiene defectos, y algunos de estos crearan problemas de seguridad. Ambos, cliente y proveedor se esforzará para identificar las vulnerabilidades tan pronto como sea posible en el ciclo de desarrollo.<br /> <br /> ;(e) La información sobre seguridad será comunicada por completo : Toda la información relevante para la seguridad se compartirá entre el cliente y el proveedor inmediatamente y completamente.<br /> <br /> ;(f) Se requerirá solo documentacion de seguridad necesaria : La documentación de seguridad no necesita ser demasiado amplia para describir claramente el diseño de seguridad, análisis de riesgo y problemas.<br /> <br /> === 3. ACTIVIDADES EN EL CICLO DE DESARROLLO ===<br /> <br /> ;(a) Entendimiento del Riesgo&amp;nbsp;<br /> :El proveedor y el cliente acuerdan trabajar juntos para entender y documentar los riesgos que enfrenta la aplicacion. Este esfuerzo debe identificar los riesgos clave para los activos y funciones importantes que provee la aplicación. Cada uno de los temas listados en la sección de requerimientos debe ser considerado.<br /> <br /> ;(b) Requerimientos&amp;nbsp;<br /> :Basado en los riesgos, el proveedor y cliente acuerda trabajar juntos para crear requerimientos de seguridad detallados como parte de la especificacion del software a ser desarrollado. Cada uno de los temas listados en la sección de requerimientos de este anexo deben ser discutidos y evaluados por ambos, cliente y proveedor. Estos requerimientos pueden ser satisfechos por software creado a la medida, software de terceros, o la plataforma.<br /> <br /> ;(c) Diseño&amp;nbsp;<br /> :El desarollador acuerda proveer documentación que explique claramente el diseño para adquirir cada uno de los requerimientos de seguridad. En muchos de los casos, esta documentacion describirá los mecanismos de seguridad, donde se incluirán dentro de la arquitectura, todos los patrones de diseño relevantes para asegurar su uso adecuado. El diseño debe especificar claramente si tales mecanismos vienen de software a la medida, software de terceros o de la plataforma.<br /> <br /> ;(d) Implementación&amp;nbsp;<br /> :El proveedor acuerda entregar y seguir un conjunto de lineamientos de codificación segura. Estos lineamientos indicarán como se le de debe dar formato, estructurar y comentar el código fuente. Todo código relacionado a seguridad debe ser comentado profundamente. Guías sobre como evitar vulnerabilidades se seguridad comunes debe ser incluida. Tambien, todo el código debe ser revisado por al menos otro desarollador basándose en los requerimientos de seguridad y los lineamientos de codificación antes de ser conciderado listo para pruebas unitarias.<br /> <br /> ;(e) Pruebas y análisis de seguridad&amp;nbsp;<br /> :El proveedor acuerda entregar y seguir un plan de pruebas de seguridad que defina cómo se realizarán las pruebas o bien establecer como cada uno de los requerimientos de seguridad va a ser complido. El nivel de rigor de esta actividad debe ser considerado y detallado en un plan. El proveedor ejecutará el plan de prueba y proveera los resultados a el cliente.<br /> <br /> ;(f) Publicación segura&amp;nbsp;<br /> :El proveedor acuerda entregar lineamientos de configuración segura que describan completamente todas las opciones de configuración relacionadas con seguridad y sus implicaciones para la seguridad del software en su conjunto. Los lineamientos deben incluir una descripción completa de las dependencias en la plataforma y como deben ser configuradas de manera segura, incluidas las del sistema operativo, servidor Web y servidor de aplicacion. La configuración predeterminada del software debe ser segura.<br /> <br /> ===4. ÁREAS CON REQUERIMIENTOS DE SEGURIDAD===<br /> <br /> Los siguientes temas/áreas deben ser considerados durante las actividades de entendimiento de riesgo y definición de requerimientos. Este esfuerzo debe producir un conjunto de requerimientos ajustados, especificos y probables. Ambos, proveedor y cliente deben ser involucrados en este proceso y deben ponerse de acuerdo sobre el conjunto final de requerimientos.<br /> <br /> ;(a) Validación de entradas y condificación : Los requerimientos deben especificar las reglas para canonicalización, validación y codificación de cada dato de entrada a la aplicación, ya sea de usuarios, sistemas de archivos, bases de datos o sistemas externos. La regla predeterminada debe ser que todas las entradas sean validadas a menos que cumplan con una especificacion detallada de que esta permitido. Además, los requerimientos deben especificar las acciones a tomar cuando se reciven entradas no válidas. Especificamente, la aplicación no debe ser susceptible a inyecciones, desbordamientos, manipulación y otros ataques con entradas de usuario corruptas.<br /> <br /> ;(b) Autentificación y manejo de sessiones : Los requerimientos deben especificar como se protegeran las credenciales para autentificación y los identificadores de sesión a través del ciclo de desarrollo de software. Los requerimientos para todas las funciones relacionadas deben ser agregadas incluyendo recuperar contraseñas, cambio de contraseñas, recordar contraseñas, desconexión y conexión multiple.<br /> <br /> ;(c) Control de Acceso : Los requerimientos deben incluir una descripcion detallada de todos los roles (grupos, privilegios, autorizaciones) usadas en la aplicación. Los requerimientos deben indicar todos los activos y funciones que provee la aplicacion. Los requerimientos deben especificar detallada y exactamente los derechos de acceso para cualquier activo y función de cada rol. Se sugiere utilizar un formato de matriz de control de acceso para documentar estas reglas.<br /> <br /> ;(d) Manejo de Errores : Los requerimientos deben detallar como se van a manejar los errores que ocurran dentro del procesamiento. Algunas aplicaciones deberían hacer lo mejor posible en caso de un error, mientras que otras deberían terminar su procesamiento inmediatamente.<br /> <br /> ;(e) Historial : Los requerimientos deben especificar que eventos son relevantes para la seguridad y necesitan ser registrados, como ataques detectados, intentos de conexión fallidos e intentos de exeder la autorización. Los requerimientos deben especificar tambien que information registrar con cada evento, incluyendo hora y fecha, descripción del evento, detalles de aplicación, y otra información útil en esfuerzos forences.<br /> <br /> ;(f) Conexiones a sistemas externos : Los requerimientos deben especifica como la autentificación y cifrado será manejado para todos los systemas externos, tales como bases de datos, directorios y servicios Web. Todas las credenciales requeridas para la comunicación con sistemas externos deben almacenarce cifradas y fuera de el código dentro de archivos de configuración. <br /> <br /> ;(g) Cifrado : Los requerimientos deben especificar que datos deben ser cifrados, como serán cifrados y como todos los certificados y otras credenciales deben ser manejadas. Las aplicaciones deben usar algoritmos estándar implementados en una librerias de cifrado que hayan sido usadas y probadas ampliamente.<br /> <br /> ;(h) Disponibilidad : Los requerimientos deben especificar como protegerse de ataques de negación de servicio. Todos los posibles ataques en la aplicacion deben ser considerados, incluyendo bloqueos de auntentificación, agotamiento de conexiones y otros ataques de agotamiento de recursos.<br /> <br /> ;(i) Configuración segura : Los requerimientos deben especificar que los valores predeterminados para todas las configuraciones relacionadas a seguridad deben ser seguras. Para propósitos de auditoría, el software deberia ser capás de producir un reporte sencillo de leer que muestre los detalles de todas las configuraciones relacionadas con seguridad.<br /> <br /> ;(j) Vulnerabilidades especificas : Los requerimientos deben incluir un conjunto de vulnerabilidades especificas que no deben estar presentes en el software. A menos que sea especificado de otra manera, el software no debe incluir ninguna de las fallas descritas en el la &quot;Lista de OWASP sobre las 10 vulnerabilidades mas críticas en aplicaciones Web&quot;.<br /> <br /> ===5. PERSONAL Y ORGANIZACIÓN===<br /> <br /> ;(a) Arquitecto en seguridad : El desarollador asignará la responsabilidad por la seguridad a un solo recurso técnico experimentado, para ser conocido como el arquitecto de seguridad del proyecto. El arquitecto de seguridad certificará la seguridad de cada entregable.<br /> <br /> ;(b) Entrenamiento en Seguridad : el proveedor será responsable de verificar que todos los miembros del equipo de desarrollo han sido entrenados en tecnicas de programación segura.<br /> <br /> ;(c) Desarrolladores dignos de confianza : El proveedor acuerda realizar las investigaciones de antecendentes apropiadas a todos los miembros del equipo de desarrollo.<br /> <br /> ===6. AMBIENTE DE DESARROLLO===<br /> <br /> ;(a) Codificación segura : El proveedor debe mencionar que herramientas se usarán en el ambiente de desarrollo de software para promover la codificación segura.<br /> <br /> ;(b) Adminstración de configuración : El proveedor debe usar un sistema de control de versiones que autentifique y registre el miembro del equipo asociado con todos los cambios en el código base, todos los archivos de configuración y compilación.<br /> <br /> ;(c) Distribución : El proveedor debe usar un proceso de compilación que construya confiablemente un archivo de distribución completo desde el código fuente. Este proceso debe incluir un método para verificar la integridad de el software entregado al cliente.<br /> <br /> ===7. LIBRERIAS, MARCOS DE DESARROLLO Y PRODUCTOS===<br /> <br /> ;(a) Apertura : El proveedor debe mencionar todas los aplicaciones de terceros usadas en el software, incluyendo todas las librerias, marcos de desarrollo, componentes y otros productos, ya sean comerciales, gratuitos, de código abierto o código cerrado.<br /> <br /> ;(b) Evaluación : El proveedor debe hacer esfuerzos rasonables para asegurar que el sofware de terceros cumple con todos los términos de este contrato y es tan seguro como el código a la medida desarrollado bajo este contrato.<br /> <br /> ===8. REVISIONES DE SEGURIDAD===<br /> <br /> ;(a) Derecho de revisión : El cliente tiene el derecho mandar revisar el software para buscar fallas de seguridad, esto a sus expesas y en cualquier momento dentro de los 60 dias despues de la entrega. El desarrollador acepta proveer apoyo rasonable al equipo de revisión proveyendo el codigo fuente y acceso a los ambientes de pruebas.<br /> <br /> ;(b) Covertura de la revisión : Las revisiones de seguridad deben cubrir todos los aspectos de el software entregado, incluyendo código a la medida, componentes, productos y configuración de sistema.<br /> <br /> ;(c) Alcance de la revisión : Al menos, la revisión debe cubrir todos los requerimientos de seguridad y debería buscar otras vulnerabilidades comunes. La revisión puede incluir una combinación de busqueda automatizada de vulnerabilidades, pruebas de intrusión, análisis estático de código fuente y revisión de código por expertos.<br /> <br /> ;(d) Problemas encontrados : Los problemas de seguridad descubiertos serán reportados a el cliente y proveedor por igual. A todos los problemas se les dará seguimiento y serán reparados como se especifique en la sección de seguimiento de problemas de seguridad de este anexo.<br /> <br /> ===9. ADMINISTRACIÓN DE PROBLEMAS DE SEGURIDAD===<br /> <br /> ;(a) Identificación : El proveedor dara seguimiento a todos los problemas de seguridad descubiertos en todo el ciclo de desarrollo, ya sea un problema en los requerimientos, diseño, implementación, pruebas, publicación u operación. El riesgo asociado con cada problema de seguridad será evaluado, documentado y reportado a el cliente tan pronto como sea posible.<br /> <br /> ;(b) Protección : El proveedor protegerá apropiadamente la información relacionada a problemas de seguridad y la documentación relacionada a ellos, esto, para ayudar a disminuir la probabilidad de las vulnerabilidades en el software operacioneal del cliente sean expuestas.<br /> <br /> ;(c) Reparación : Los problemas de seguridad que sean indentificados antes de la entrega deben ser reparados por el proveedor. Los problemas de seguridad descubiertos despues de la entrega deben ser manejados en la misma manera que otros problemas funcionales según lo especificado en este contrato.<br /> <br /> ===10. CERTEZA===<br /> <br /> ;(a) Certeza : El proveedor proveera un &quot;paquete de certificación&quot; consistente en la documentación de seguridad creada a traves del proceso de desarrollo. El paquete deberá establecer que los requerimientos de seguridad, diseño, implementación y resultados de pruebas fueron completados apropiadamente y todos los problemas de seguridad fueron resueltos apropiadamente.<br /> <br /> ;(b) Auto-Certificación : El aquitecto de seguridad certificará que el software cumple con los requerimientos de seguridad, que todas las actividades de seguridad se realizaron, y que todos los problemas de seguridad identificados han sido documentados y resueltos. Cualquier excepción a el estado de la certificacion debe estar totalmente documentada al momento de la entrega.<br /> <br /> ;(c) No código malicioso : El proveedor garantize que el sofware no debe contener ningun código que no se alinee a algun requerimiento del software y debilite la seguridad de la aplicación, incluyendo viruses, gusanos, bombas de tiempo, puertas traseras, caballos de troya, huevos de pascua y cualquier otra forma de código malicioso.<br /> <br /> ===11. CONCENTIMIENTO Y MANTENIMIENTO DE LA SEGURIDAD===<br /> <br /> ;(a) Consentimiento : El software no debe ser considerado como aceptado hasta que el paquete de certificación este completo y todos los problemas de seguridad han sido resueltos.<br /> <br /> ;(b) Investigación de problemas de seguridad : Despues del concentimiento, si se sospecha (razonablemente) o descubren problemas de seguridad, el proveedor deberá asisitir al cliente en realizar una investigación para determinar la naturaleza del problema. El problema debe ser considerado &quot;nuevo&quot; si no es cubierto por los requerientos de seguridad y esta fuera de el alcance (razonable) de las pruebas de seguridad.<br /> <br /> ;(c) Problemas de seguridad nuevos : El proveedor y el cliente consientes en medir el alcance y esfuerzo requerido para resolver problemas de seguridad nuevos, y negociad de buena fe para alcanzar un acuerdo y realizar el trabajor requerido para solucionarlos.<br /> <br /> ;(d) Otros problemas de seguridad : El proveedor debe usar todos los esfuersos comercialmente rasonables consistentes con practicas de desarrollo comunes en la industria, tomando en cuenta la severidad de el riesgo, para resolver todos los problemas de seguridad considerados nuevos tan pronto como sea posible.<br /> <br /> [[Category:OWASP Legal Project]]<br /> <br /> __NOTOC__</div>

Jorge Correa https://wiki.owasp.org/index.php?title=Anexo_para_Contrato_de_Software_Seguro_de_OWASP&diff=79731 2010-03-12T13:57:40Z

<p>Jorge Correa: </p> <hr /> <div>'''ANEXO DE CONTRATO PARA DESAROLLO DE SOFTWARE SEGURO'''<br /> <br /> ADVERTENCIA: ESTE DOCUMENTO DEBE SER CONSIDERADO COMO UNA GUÍA SOLAMENTE.<br /> OWASP RECOMIENDA VEHEMENTEMENTE QUE CONSULTE UN ABOGADO CALIFICADO<br /> PARA AYUDARLE A NEGOCIAR UN CONTRATO DE SOFTWARE<br /> <br /> == Introducción ==<br /> <br /> Este anexo de contrato pretende ayudar a los proveedores de software y sus clientes a negociar y capturar importantes términos y condiciones contractuales relacionadas a la seguridad en el Software a ser desarrollado o entregado. La razon para este proyecto es que la mayoría de los contratos no mencionan estos temas, y las partes frecuentamente tienen puntos de vista dramaticamente diferentes a lo que en ralidad fue acordado. Creemos que articular claramente estos términos es la mejor manera de asegurarse que ambas partes pueden hacer desiciones informadas sobre como proceder. <br /> <br /> &quot;La seguridad del software comercial mejorará cuando el mercado demande mejor seguridad.<br /> Al menos, cada petición para propuestas de software debería pedir a los vendedores <br /> detallar como van ellos a probar sus productos para encotrar vulnerabilidades de<br /> seguridad. Este paso empezará convenciendo a los vendedores de software empaquetado<br /> y proveedores externos que las compañias valoran la seguridad.&quot;<br /> <br /> -- John Pescatore, Director de investiagacion con Gartner&lt;br&gt; <br /> <br /> Pedimos a los clientes y proveedores que usen este documento como un marco para discutir<br /> espectativas y negociar responsabilidades. Este anexo se creó para ser añadido a un<br /> contrato de desarrollo de software. Estos términos son negociables, significa que ellos<br /> pueden y deben ser discutidos por el cliente y el proveedor.<br /> <br /> == SOBRE EL PROYECTO ==<br /> <br /> Este documento fue creado por la fundación OWASP (Open Web Application Security Project por sus siglas en Inglés), una organización sin animo de lucro con el objetivo de crear herramientas y documentación, gratuita y abierta para asegurar software. Para facilitar su uso en contratación privada, este documento es de dominio publico. Puede encontrar detalles adicionales sobre este proyecto en http://www.owasp.com/index.php/OWASP_Legal_Project. Son Bienvenidos comentarios de ambos, productores y consumidores de software, asi como de la comunidad legal. <br /> <br /> OWASP reconoce gratamente la contribución especial de [http://www.aspectsecurity.com Aspect Security] por su rol en la investigación y preparación de este documento.<br /> <br /> ==OBJECIONES==<br /> <br /> Las siguientes páginas cubren algunas objeciones que escuchamos frecuentemente sobre usar este lenguaje en contratos de desarrollo de software:<br /> <br /> === PERO NO TODOS LOS TÉRMINOS SON CORRECTOS PARA NOSOTROS… ===<br /> <br /> Este documento debe ser considerado un punto de inicio para su contrato. Puede que no le gusten todas las actividades, o puede querer proponer mas. Puede querer asignar responsabilidades de manera diferente. Este documento no pretende capturar exactamente las necesidades de todos los clientes y proveedores de software. Pretende proveer un marco para discutir temas clave, importantes para asegurarse que el software se cree de forma segura. Despues de que tengan una discusión sobre seguridad y alcancen un acuerdo. Puede ajustar el convenio para que concuerde con el contrato.<br /> <br /> === PERO, ¿QUIEN DEBE PAGAR POR ESTAS ACTIVIDADES?… ===<br /> <br /> Este contrato no es sobre poner mas peso al desarollo de software. La pregunta no es sobre si hay costos asociados con seguridad (por supuesto que hay). La pregunta correcta es qué actividades deberían hacerse por ambas partes para minimizar costos, y cuando deberían ocurrir. <br /> <br /> Este anexo no menciona (intensionalmente) sobre el detalle de quién debería pagar por la actividades descritas. Mientras muchas de estas actividades deben estar pasando ya, y son esperadas por muchos clientes, ellas no estan practicadas regularmente en la industria del software. La cuestion de quién paga (y cuándo) debe ser parte de la negociación. <br /> <br /> Calcular el costo de la seguridad es muy difícil. Auque hay costos asociados con realizar actividades de seguridad, hay también costos importantes asociados con ignorar estas actividades. Estamos convencidos el mejor costo-beneficio para desarrollar software es reducir la probabilidad de que fallas de seguridad sean introducidas y minimzar el tiempo entre introducir una falla y arreglarla. <br /> <br /> Una distición importante a hacer cuando calculamos costos es entre construir mecanismos de seguridad y las actividades para asegurarse que esos mecanismos sean correctos y efectivos. Intentar agregar mecanismoa al final de el ciclo de desarrollo puede causar serios problemas de diseño e incrementará el costo dramáticamente. Este convenio promueve decisiones sobre mecanismos para minimizar estos costos. Similarmente, esperar hasta justo antes de la puesta en producción para hacer actividades de aseguramiento, tales como revisión de código y pruebas de intrusión, tambien incrementaría los costos dramaticamente. Creemos que el mejor costo-beneficio para ganar certeza es poner un nivel constante de esfuerzo en el aseguramiento a través del ciclo de desarrollo.<br /> <br /> === PERO EL NIVEL DE RIGOR ESTA INCORRECTO…. ===<br /> <br /> Este convenio asume que el software que esta siendo desarrollado es razonablemente importante para una empresa grande o agencia de gobierno. Hemos seleccionado un &quot;nivel de rigor&quot; para el convenio que es alcanzable por la mayoria de las organizaciones proveedoras de software, e identificaría y manejaría los riesgos más comunes. <br /> <br /> Sin embargo, para el software que va a ser usado en aplicaciones críticas, como aplicaciones médicas, financieras o relacionadas con el ejército. Puede querer incrementar el nivel de rigor. Puede querer agregar revisiones, documentación y actividades adicionales de prueba. Puede querer mejorar el proceso de encontrar, diagnosticar y remediar vulnerabilidades. Para aplicaciones menos sensibles, puede desear reducir o remover actividades.<br /> <br /> === PERO NOSOTROS NO PODEMOS ACEPTAR TANTO RIESGO… ===<br /> <br /> Este convenio pretende facilitar la discusión sobre quién tomaría el riesgo por las vulnerabilidades de seguridad en el software. Por un lado del espectro, el cliente podría tomar todo el riesgo y el proveedor podría entregar código con muchas vulnerabilidades. Por el otro extremo, el proveedor podría tomar todo el riesgo y asumir la responsabilidad de entregar código perfecto. Ambos extremos son irrealizables. <br /> <br /> Actualmente, en este convenio, el proveedor toma el riesgo por problemas que sean descubiertos en los requerimientos o deben ser cubiertos por esfuerzos razonables en pruebas. Pero la remediación de &quot;nuevos&quot; problemas de seguridad tendría que ser pagado por el cliente. Creemos que este es un equilibrio funcional, ya que limita el riesgo adquirido por el proveedor y promueve obtener requerimientos de seguridad por anticipado. Pero hay muchas otras posibles soluciones a este problema. Por favor, dejenos saber si tiene sugerencias alternas, podriamos incluirlas en versiones futuras de este documento. <br /> <br /> Note que la discusión aqui solo cubre el riesgo asociado con arreglar las vulnerabilidades de seguridad en el código, y no incluye los costos asociados con recuperarse de incidentes de seguridad relacionados con explotar cualquiera de esas vulnerabilidades. Estamos interesados en las mejores prácticas en esta area.<br /> <br /> === PERO COMO PODEMOS ASEGURAR CÓDIGO DE TERCEROS… ===<br /> <br /> Casi todos los proyectos de sofware tienen una cantidad importante de código de terceros como librerias, frameworks y productos. Desde la perspectiva de seguridad, este código es tan importante como el código desarrollado a la medida para su proyecto. Creemos que la responsabilidad de garantizar la seguridad de este código es llevada mejor por el proveedor, aunque ellos podrían no tener toda la capacidad para garantizar la seguridad por ellos mismos. Sin embargo, la seguridad puede ser parte de el la desición de &quot;construir o comprar&quot;, y esta parece ser la mejor manera de promoverla. <br /> <br /> El proveedor, por supuesto, tiene la opción de pasar la responsabilidad al proveedor del software de terceros. El desarrollador puede también analizar el código de terceros por él mismo o contratar expertos en seguridad para analizarlo por él.<br /> <br /> === PERO PORQUE DEBO PASAR POR TODO ESTE PROBLEMA… ===<br /> <br /> En última instancia, creemos que no hay alternativa para hacer de la seguridad una parte de el proceso de contratación de software. Actualmente, creemos que hay serios malentendidos sobre la seguridad del código que esta siendo desarrollado bajo muchos contratos de desarrollo de software. Esto puede solamente llevar a una cara litigación y a desiciones hechas por individuos con poca experiencia y entendimiento sobre software. Lea el [[Secure software contracting hypothetical case study|Caso de estudio hipotético sobre contratación de software seguro]] para una discusión completa de este problema. <br /> <br /> Hay muchos beneficios al trabajar con este convenio. El principal es que pondrá claras las expectativas entre las partes involucradas. En algunos casos ayudará a evitar demandas cuando problemas de seguridad difíciles aparecen en el software. Tambien, estas son las mismas actividades requeridas por muchas razónes legales y de conformidad con estándares/leyes.<br /> <br /> === PERO ES MUY DIFÍCIL PRODUCIR TODA ESTA DOCUMENTACIÓN… ===<br /> <br /> OWASP no promueve la documentación por la simpre documentación. Este convenio está enfocado en promover la calidad, no la cantidad. Creemos que puede ser posible (en algunos proyectos) cumplir con este contrato con una pequeña evaluación de riesgo, algunas páginas de requerimientos, un pequeño documento de diseño de seguridad, un plan de pruebas, y algunos resultados de pruebas. <br /> <br /> El objetivo de esta documentación es simplemente asegurar, en cada etapa del desarrollo de software, que se ha puesto la atención apropiada en la seguridad. Un beneficio adicional es que esta documentación puede ser recolectada en conjunto para formar un &quot;paquete de certificación&quot; que básicamente esboce el argumento de porque deberiamos confiar que el software hará lo que dice.<br /> <br /> ==ANEXO DE CONTRATO==<br /> <br /> ===1. INTRODUCCIÓN===<br /> <br /> Esta anexo esta hecho para _____________________ (&quot;convenio&quot;) entre el Cliente y el proveedor. Tanto el Cliente como el proveedor acuerdan maximisar la seguridad del software de acuerdo a los siguientes términos.<br /> <br /> <br /> ===2. FILOSOFÍA===<br /> <br /> Esta anexo pretende aclarar los derechos y obligaciones relacionados a seguridad de todas las partes en una relacion de desarrollo de software. Al mayor nivel, las partes acuerdan que:<br /> <br /> ;(a) Las desiciones de seguridad estarán basadas en el riesgo : Las desciciones sobre la seguridad seran tomadas en conunto por el cliente y el proveedor basandose en un firme entendimiento de el riesgo involucrado. <br /> <br /> ;(b) Las actividades de seguridad estarán balanceadas : El esfurzo de seguridad será distribuido equitativamente a través de todo el ciclo de desarollo de software.<br /> <br /> ;(c) Las actividades de seguridad estarán integradas : Todas las actividades y documentación discutidas aqui pueden y deben ser integradas dentro del ciclo de desarrollo de software del proveedor y no mantenerse separadas de el resto del proyecto. Nada en este anexo implica algún processo de desarrollo de software en particular.<br /> <br /> ;(d) Se esperan vulnerabilidades : Todo software contiene defectos, y algunos de estos crearan problemas de seguridad. Ambos, cliente y proveedor se esforzará para identificar las vulnerabilidades tan pronto como sea posible en el ciclo de desarrollo.<br /> <br /> ;(e) La información sobre seguridad será comunicada por completo : Toda la información relevante para la seguridad se compartirá entre el cliente y el proveedor inmediatamente y completamente.<br /> <br /> ;(f) Se requerirá solo documentacion de seguridad necesaria : La documentación de seguridad no necesita ser demasiado amplia para describir claramente el diseño de seguridad, análisis de riesgo y problemas.<br /> <br /> === 3. ACTIVIDADES EN EL CICLO DE DESARROLLO ===<br /> <br /> ;(a) Entendimiento del Riesgo&amp;nbsp;<br /> :El proveedor y el cliente acuerdan trabajar juntos para entender y documentar los riesgos que enfrenta la aplicacion. Este esfuerzo debe identificar los riesgos clave para los activos y funciones importantes que provee la aplicación. Cada uno de los temas listados en la sección de requerimientos debe ser considerado.<br /> <br /> ;(b) Requerimientos&amp;nbsp;<br /> :Basado en los riesgos, el proveedor y cliente acuerda trabajar juntos para crear requerimientos de seguridad detallados como parte de la especificacion del software a ser desarrollado. Cada uno de los temas listados en la sección de requerimientos de este anexo deben ser discutidos y evaluados por ambos, cliente y proveedor. Estos requerimientos pueden ser satisfechos por software creado a la medida, software de terceros, o la plataforma.<br /> <br /> ;(c) Diseño&amp;nbsp;<br /> :El desarollador acuerda proveer documentación que explique claramente el diseño para adquirir cada uno de los requerimientos de seguridad. En muchos de los casos, esta documentacion describirá los mecanismos de seguridad, donde se incluirán dentro de la arquitectura, todos los patrones de diseño relevantes para asegurar su uso adecuado. El diseño debe especificar claramente si tales mecanismos vienen de software a la medida, software de terceros o de la plataforma.<br /> <br /> ;(d) Implementación&amp;nbsp;<br /> :El proveedor acuerda entregar y seguir un conjunto de lineamientos de codificación segura. Estos lineamientos indicarán como se le de debe dar formato, estructurar y comentar el código fuente. Todo código relacionado a seguridad debe ser comentado profundamente. Guías sobre como evitar vulnerabilidades se seguridad comunes debe ser incluida. Tambien, todo el código debe ser revisado por al menos otro desarollador basándose en los requerimientos de seguridad y los lineamientos de codificación antes de ser conciderado listo para pruebas unitarias.<br /> <br /> ;(e) Pruebas y análisis de seguridad&amp;nbsp;<br /> :El proveedor acuerda entregar y seguir un plan de pruebas de seguridad que defina cómo se realizarán las pruebas o bien establecer como cada uno de los requerimientos de seguridad va a ser complido. El nivel de rigor de esta actividad debe ser considerado y detallado en un plan. El proveedor ejecutará el plan de prueba y proveera los resultados a el cliente.<br /> <br /> ;(f) Publicación segura&amp;nbsp;<br /> :El proveedor acuerda entregar lineamientos de configuración segura que describan completamente todas las opciones de configuración relacionadas con seguridad y sus implicaciones para la seguridad del software en su conjunto. Los lineamientos deben incluir una descripción completa de las dependencias en la plataforma y como deben ser configuradas de manera segura, incluidas las del sistema operativo, servidor Web y servidor de aplicacion. La configuración predeterminada del software debe ser segura.<br /> <br /> ===4. ÁREAS CON REQUERIMIENTOS DE SEGURIDAD===<br /> <br /> Los siguientes temas/áreas deben ser considerados durante las actividades de entendimiento de riesgo y definición de requerimientos. Este esfuerzo debe producir un conjunto de requerimientos ajustados, especificos y probables. Ambos, proveedor y cliente deben ser involucrados en este proceso y deben ponerse de acuerdo sobre el conjunto final de requerimientos.<br /> <br /> ;(a) Validación de entradas y condificación : Los requerimientos deben especificar las reglas para canonicalización, validación y codificación de cada dato de entrada a la aplicación, ya sea de usuarios, sistemas de archivos, bases de datos o sistemas externos. La regla predeterminada debe ser que todas las entradas sean validadas a menos que cumplan con una especificacion detallada de que esta permitido. Además, los requerimientos deben especificar las acciones a tomar cuando se reciven entradas no válidas. Especificamente, la aplicación no debe ser susceptible a inyecciones, desbordamientos, manipulación y otros ataques con entradas de usuario corruptas.<br /> <br /> ;(b) Autentificación y manejo de sessiones : Los requerimientos deben especificar como se protegeran las credenciales para autentificación y los identificadores de sesión a través del ciclo de desarrollo de software. Los requerimientos para todas las funciones relacionadas deben ser agregadas incluyendo recuperar contraseñas, cambio de contraseñas, recordar contraseñas, desconexión y conexión multiple.<br /> <br /> ;(c) Control de Acceso : Los requerimientos deben incluir una descripcion detallada de todos los roles (grupos, privilegios, autorizaciones) usadas en la aplicación. Los requerimientos deben indicar todos los activos y funciones que provee la aplicacion. Los requerimientos deben especificar detallada y exactamente los derechos de acceso para cualquier activo y función de cada rol. Se sugiere utilizar un formato de matriz de control de acceso para documentar estas reglas.<br /> <br /> ;(d) Manejo de Errores : Los requerimientos deben detallar como se van a manejar los errores que ocurran dentro del procesamiento. Algunas aplicaciones deberían hacer lo mejor posible en caso de un error, mientras que otras deberían terminar su procesamiento inmediatamente.<br /> <br /> ;(e) Historial : Los requerimientos deben especificar que eventos son relevantes para la seguridad y necesitan ser registrados, como ataques detectados, intentos de conexión fallidos e intentos de exeder la autorización. Los requerimientos deben especificar tambien que information registrar con cada evento, incluyendo hora y fecha, descripción del evento, detalles de aplicación, y otra información útil en esfuerzos forences.<br /> <br /> ;(f) Conexiones a sistemas externos : Los requerimientos deben especifica como la autentificación y cifrado será manejado para todos los systemas externos, tales como bases de datos, directorios y servicios Web. Todas las credenciales requeridas para la comunicación con sistemas externos deben almacenarce cifradas y fuera de el código dentro de archivos de configuración. <br /> <br /> ;(g) Cifrado : Los requerimientos deben especificar que datos deben ser cifrados, como serán cifrados y como todos los certificados y otras credenciales deben ser manejadas. Las aplicaciones deben usar algoritmos estándar implementados en una librerias de cifrado que hayan sido usadas y probadas ampliamente.<br /> <br /> ;(h) Disponibilidad : Los requerimientos deben especificar como protegerse de ataques de negación de servicio. Todos los posibles ataques en la aplicacion deben ser considerados, incluyendo bloqueos de auntentificación, agotamiento de conexiones y otros ataques de agotamiento de recursos.<br /> <br /> ;(i) Configuración segura : Los requerimientos deben especificar que los valores predeterminados para todas las configuraciones relacionadas a seguridad deben ser seguras. Para propósitos de auditoría, el software deberia ser capás de producir un reporte sencillo de leer que muestre los detalles de todas las configuraciones relacionadas con seguridad.<br /> <br /> ;(j) Vulnerabilidades especificas : Los requerimientos deben incluir un conjunto de vulnerabilidades especificas que no deben estar presentes en el software. A menos que sea especificado de otra manera, el software no debe incluir ninguna de las fallas descritas en el la &quot;Lista de OWASP sobre las 10 vulnerabilidades mas críticas en aplicaciones Web&quot;.<br /> <br /> ===5. PERSONAL Y ORGANIZACIÓN===<br /> <br /> ;(a) Arquitecto en seguridad : El desarollador asignará la responsabilidad por la seguridad a un solo recurso técnico experimentado, para ser conocido como el arquitecto de seguridad del proyecto. El arquitecto de seguridad certificará la seguridad de cada entregable.<br /> <br /> ;(b) Entrenamiento en Seguridad : el proveedor será responsable de verificar que todos los miembros del equipo de desarrollo han sido entrenados en tecnicas de programación segura.<br /> <br /> ;(c) Desarrolladores dignos de confianza : El proveedor acuerda realizar las investigaciones de antecendentes apropiadas a todos los miembros del equipo de desarrollo.<br /> <br /> ===6. AMBIENTE DE DESARROLLO===<br /> <br /> ;(a) Codificación segura : El proveedor debe mencionar que herramientas se usarán en el ambiente de desarrollo de software para promover la codificación segura.<br /> <br /> ;(b) Adminstración de configuración : El proveedor debe usar un sistema de control de versiones que autentifique y registre el miembro del equipo asociado con todos los cambios en el código base, todos los archivos de configuración y compilación.<br /> <br /> ;(c) Distribución : El proveedor debe usar un proceso de compilación que construya confiablemente un archivo de distribución completo desde el código fuente. Este proceso debe incluir un método para verificar la integridad de el software entregado al cliente.<br /> <br /> ===7. LIBRERIAS, MARCOS DE DESARROLLO Y PRODUCTOS===<br /> <br /> ;(a) Apertura : El proveedor debe mencionar todas los aplicaciones de terceros usadas en el software, incluyendo todas las librerias, marcos de desarrollo, componentes y otros productos, ya sean comerciales, gratuitos, de código abierto o código cerrado.<br /> <br /> ;(b) Evaluación : El proveedor debe hacer esfuerzos rasonables para asegurar que el sofware de terceros cumple con todos los términos de este contrato y es tan seguro como el código a la medida desarrollado bajo este contrato.<br /> <br /> ===8. REVISIONES DE SEGURIDAD===<br /> <br /> ;(a) Derecho de revisión : El cliente tiene el derecho mandar revisar el software para buscar fallas de seguridad, esto a sus expesas y en cualquier momento dentro de los 60 dias despues de la entrega. El desarrollador acepta proveer apoyo rasonable al equipo de revisión proveyendo el codigo fuente y acceso a los ambientes de pruebas.<br /> <br /> ;(b) Covertura de la revisión : Las revisiones de seguridad deben cubrir todos los aspectos de el software entregado, incluyendo código a la medida, componentes, productos y configuración de sistema.<br /> <br /> ;(c) Alcance de la revisión : Al menos, la revisión debe cubrir todos los requerimientos de seguridad y debería buscar otras vulnerabilidades comunes. La revisión puede incluir una combinación de busqueda automatizada de vulnerabilidades, pruebas de intrusión, análisis estático de código fuente y revisión de código por expertos.<br /> <br /> ;(d) Problemas encontrados : Los problemas de seguridad descubiertos serán reportados a el cliente y proveedor por igual. A todos los problemas se les dará seguimiento y serán reparados como se especifique en la sección de seguimiento de problemas de seguridad de este anexo.<br /> <br /> ===9. ADMINISTRACIÓN DE PROBLEMAS DE SEGURIDAD===<br /> <br /> ;(a) Identificación : El proveedor dara seguimiento a todos los problemas de seguridad descubiertos en todo el ciclo de desarrollo, ya sea un problema en los requerimientos, diseño, implementación, pruebas, publicación u operación. El riesgo asociado con cada problema de seguridad será evaluado, documentado y reportado a el cliente tan pronto como sea posible.<br /> <br /> ;(b) Protección : El proveedor protegerá apropiadamente la información relacionada a problemas de seguridad y la documentación relacionada a ellos, esto, para ayudar a disminuir la probabilidad de las vulnerabilidades en el software operacioneal del cliente sean expuestas.<br /> <br /> ;(c) Reparación : Los problemas de seguridad que sean indentificados antes de la entrega deben ser reparados por el proveedor. Los problemas de seguridad descubiertos despues de la entrega deben ser manejados en la misma manera que otros problemas funcionales según lo especificado en este contrato.<br /> <br /> ===10. CERTEZA===<br /> <br /> ;(a) Certeza : El proveedor proveera un &quot;paquete de certificación&quot; consistente en la documentación de seguridad creada a traves del proceso de desarrollo. El paquete deberá establecer que los requerimientos de seguridad, diseño, implementación y resultados de pruebas fueron completados apropiadamente y todos los problemas de seguridad fueron resueltos apropiadamente.<br /> <br /> ;(b) Auto-Certificación : El aquitecto de seguridad certificará que el software cumple con los requerimientos de seguridad, que todas las actividades de seguridad se realizaron, y que todos los problemas de seguridad identificados han sido documentados y resueltos. Cualquier excepción a el estado de la certificacion debe estar totalmente documentada al momento de la entrega.<br /> <br /> ;(c) No código malicioso : El proveedor garantize que el sofware no debe contener ningun código que no se alinee a algun requerimiento del software y debilite la seguridad de la aplicación, incluyendo viruses, gusanos, bombas de tiempo, puertas traseras, caballos de troya, huevos de pascua y cualquier otra forma de código malicioso.<br /> <br /> ===11. CONCENTIMIENTO Y MANTENIMIENTO DE LA SEGURIDAD===<br /> <br /> ;(a) Consentimiento : El software no debe ser considerado como aceptado hasta que el paquete de certificación este completo y todos los problemas de seguridad han sido resueltos.<br /> <br /> ;(b) Investigación de problemas de seguridad : Despues del concentimiento, si se sospecha (razonablemente) o descubren problemas de seguridad, el proveedor deberá asisitir al cliente en realizar una investigación para determinar la naturaleza del problema. El problema debe ser considerado &quot;nuevo&quot; si no es cubierto por los requerientos de seguridad y esta fuera de el alcance (razonable) de las pruebas de seguridad.<br /> <br /> ;(c) Problemas de seguridad nuevos : El proveedor y el cliente consientes en medir el alcance y esfuerzo requerido para resolver problemas de seguridad nuevos, y negociad de buena fe para alcanzar un acuerdo y realizar el trabajor requerido para solucionarlos.<br /> <br /> ;(d) Otros problemas de seguridad : El proveedor debe usar todos los esfuersos comercialmente rasonables consistentes con practicas de desarrollo comunes en la industria, tomando en cuenta la severidad de el riesgo, para resolver todos los problemas de seguridad considerados nuevos tan pronto como sea posible.<br /> <br /> [[Category:OWASP Legal Project]]<br /> <br /> __NOTOC__</div>

Jorge Correa https://wiki.owasp.org/index.php?title=Anexo_para_Contrato_de_Software_Seguro_de_OWASP&diff=79728 2010-03-12T13:52:03Z

<p>Jorge Correa: </p> <hr /> <div>'''ANEXO DE CONTRATO PARA DESAROLLO DE SOFTWARE SEGURO'''<br /> <br /> ADVERTENCIA: ESTE DOCUMENTO DEBE SER CONSIDERADO COMO UNA GUÍA SOLAMENTE.<br /> OWASP RECOMIENDA VEHEMENTEMENTE QUE CONSULTE UN ABOGADO CALIFICADO<br /> PARA AYUDARLE A NEGOCIAR UN CONTRATO DE SOFTWARE<br /> <br /> == Introducción ==<br /> <br /> Este anexo de contrato pretende ayudar a los proveedores de software y sus clientes a negociar y capturar importantes términos y condiciones contractuales relacionadas a la seguridad en el Software a ser desarrollado o entregado. La razon para este proyecto es que la mayoría de los contratos no mencionan estos temas, y las partes frecuentamente tienen puntos de vista dramaticamente diferentes a lo que en ralidad fue acordado. Creemos que articular claramente estos términos es la mejor manera de asegurarse que ambas partes pueden hacer desiciones informadas sobre como proceder. <br /> <br /> &quot;La seguridad del software comercial mejorará cuando el mercado demande mejor seguridad.<br /> Al menos, cada petición para propuestas de software debería pedir a los vendedores <br /> detallar como van ellos a probar sus productos para encotrar vulnerabilidades de<br /> seguridad. Este paso empezará convenciendo a los vendedores de software empaquetado<br /> y proveedores externos que las compañias valoran la seguridad.&quot;<br /> <br /> -- John Pescatore, Director de investiagacion con Gartner&lt;br&gt; <br /> <br /> Pedimos a los clientes y proveedores que usen este documento como un marco para discutir<br /> espectativas y negociar responsabilidades. Este anexo se creó para ser añadido a un<br /> contrato de desarrollo de software. Estos términos son negociables, significa que ellos<br /> pueden y deben ser discutidos por el cliente y el proveedor.<br /> <br /> == SOBRE EL PROYECTO ==<br /> <br /> Este documento fue creado por la fundación OWASP (Open Web Application Security Project por sus siglas en Inglés), una organización sin animo de lucro con el objetivo de crear herramientas y documentación, gratuita y abierta para asegurar software. Para facilitar su uso en contratación privada, este documento es de dominio publico. Puede encontrar detalles adicionales sobre este proyecto en http://www.owasp.com/index.php/OWASP_Legal_Project. Son Bienvenidos comentarios de ambos, productores y consumidores de software, asi como de la comunidad legal. <br /> <br /> OWASP reconoce gratamente la contribución especial de [http://www.aspectsecurity.com Aspect Security] por su rol en la investigación y preparación de este documento.<br /> <br /> ==OBJECIONES==<br /> <br /> Las siguientes páginas cubren algunas objeciones que escuchamos frecuentemente sobre usar este lenguaje en contratos de desarrollo de software:<br /> <br /> === PERO NO TODOS LOS TÉRMINOS SON CORRECTOS PARA NOSOTROS… ===<br /> <br /> Este documento debe ser considerado un punto de inicio para su contrato. Puede que no le gusten todas las actividades, o puede querer proponer mas. Puede querer asignar responsabilidades de manera diferente. Este documento no pretende capturar exactamente las necesidades de todos los clientes y proveedores de software. Pretende proveer un marco para discutir temas clave, importantes para asegurarse que el software se cree de forma segura. Despues de que tengan una discusión sobre seguridad y alcancen un acuerdo. Puede ajustar el convenio para que concuerde con el contrato.<br /> <br /> === PERO, ¿QUIEN DEBE PAGAR POR ESTAS ACTIVIDADES?… ===<br /> <br /> Este contrato no es sobre poner mas peso al desarollo de software. La pregunta no es sobre si hay costos asociados con seguridad (por supuesto que hay). La pregunta correcta es qué actividades deberían hacerse por ambas partes para minimizar costos, y cuando deberían ocurrir. <br /> <br /> Este anexo no menciona (intensionalmente) sobre el detalle de quién debería pagar por la actividades descritas. Mientras muchas de estas actividades deben estar pasando ya, y son esperadas por muchos clientes, ellas no estan practicadas regularmente en la industria del software. La cuestion de quién paga (y cuándo) debe ser parte de la negociación. <br /> <br /> Calcular el costo de la seguridad es muy difícil. Auque hay costos asociados con realizar actividades de seguridad, hay también costos importantes asociados con ignorar estas actividades. Estamos convencidos el mejor costo-beneficio para desarrollar software es reducir la probabilidad de que fallas de seguridad sean introducidas y minimzar el tiempo entre introducir una falla y arreglarla. <br /> <br /> Una distición importante a hacer cuando calculamos costos es entre construir mecanismos de seguridad y las actividades para asegurarse que esos mecanismos sean correctos y efectivos. Intentar agregar mecanismoa al final de el ciclo de desarrollo puede causar serios problemas de diseño e incrementará el costo dramáticamente. Este convenio promueve decisiones sobre mecanismos para minimizar estos costos. Similarmente, esperar hasta justo antes de la puesta en producción para hacer actividades de aseguramiento, tales como revisión de código y pruebas de intrusión, tambien incrementaría los costos dramaticamente. Creemos que el mejor costo-beneficio para ganar certeza es poner un nivel constante de esfuerzo en el aseguramiento a través del ciclo de desarrollo.<br /> <br /> === PERO EL NIVEL DE RIGOR ESTA INCORRECTO…. ===<br /> <br /> Este convenio asume que el software que esta siendo desarrollado es razonablemente importante para una empresa grande o agencia de gobierno. Hemos seleccionado un &quot;nivel de rigor&quot; para el convenio que es alcanzable por la mayoria de las organizaciones proveedoras de software, e identificaría y manejaría los riesgos más comunes. <br /> <br /> Sin embargo, para el software que va a ser usado en aplicaciones críticas, como aplicaciones médicas, financieras o relacionadas con el ejército. Puede querer incrementar el nivel de rigor. Puede querer agregar revisiones, documentación y actividades adicionales de prueba. Puede querer mejorar el proceso de encontrar, diagnosticar y remediar vulnerabilidades. Para aplicaciones menos sensibles, puede desear reducir o remover actividades.<br /> <br /> === PERO NOSOTROS NO PODEMOS ACEPTAR TANTO RIESGO… ===<br /> <br /> Este convenio pretende facilitar la discusión sobre quién tomaría el riesgo por las vulnerabilidades de seguridad en el software. Por un lado del espectro, el cliente podría tomar todo el riesgo y el proveedor podría entregar código con muchas vulnerabilidades. Por el otro extremo, el proveedor podría tomar todo el riesgo y asumir la responsabilidad de entregar código perfecto. Ambos extremos son irrealizables. <br /> <br /> Actualmente, en este convenio, el proveedor toma el riesgo por problemas que sean descubiertos en los requerimientos o deben ser cubiertos por esfuerzos razonables en pruebas. Pero la remediación de &quot;nuevos&quot; problemas de seguridad tendría que ser pagado por el cliente. Creemos que este es un equilibrio funcional, ya que limita el riesgo adquirido por el proveedor y promueve obtener requerimientos de seguridad por anticipado. Pero hay muchas otras posibles soluciones a este problema. Por favor, dejenos saber si tiene sugerencias alternas, podriamos incluirlas en versiones futuras de este documento. <br /> <br /> Note que la discusión aqui solo cubre el riesgo asociado con arreglar las vulnerabilidades de seguridad en el código, y no incluye los costos asociados con recuperarse de incidentes de seguridad relacionados con explotar cualquiera de esas vulnerabilidades. Estamos interesados en las mejores prácticas en esta area.<br /> <br /> === PERO COMO PODEMOS ASEGURAR CÓDIGO DE TERCEROS… ===<br /> <br /> Casi todos los proyectos de sofware tienen una cantidad importante de código de terceros como librerias, frameworks y productos. Desde la perspectiva de seguridad, este código es tan importante como el código desarrollado a la medida para su proyecto. Creemos que la responsabilidad de garantizar la seguridad de este código es llevada mejor por el proveedor, aunque ellos podrían no tener toda la capacidad para garantizar la seguridad por ellos mismos. Sin embargo, la seguridad puede ser parte de el la desición de &quot;construir o comprar&quot;, y esta parece ser la mejor manera de promoverla. <br /> <br /> El proveedor, por supuesto, tiene la opción de pasar la responsabilidad al proveedor del software de terceros. El desarrollador puede también analizar el código de terceros por él mismo o contratar expertos en seguridad para analizarlo por él.<br /> <br /> === PERO PORQUE DEBO PASAR POR TODO ESTE PROBLEMA… ===<br /> <br /> En última instancia, creemos que no hay alternativa para hacer de la seguridad una parte de el proceso de contratación de software. Actualmente, creemos que hay serios malentendidos sobre la seguridad del código que esta siendo desarrollado bajo muchos contratos de desarrollo de software. Esto puede solamente llevar a una cara litigación y a desiciones hechas por individuos con poca experiencia y entendimiento sobre software. Lea el [[Secure software contracting hypothetical case study|Caso de estudio hipotético sobre contratación de software seguro]] para una discusión completa de este problema. <br /> <br /> Hay muchos beneficios al trabajar con este convenio. El principal es que pondrá claras las expectativas entre las partes involucradas. En algunos casos ayudará a evitar demandas cuando problemas de seguridad difíciles aparecen en el software. Tambien, estas son las mismas actividades requeridas por muchas razónes legales y de conformidad con estándares/leyes.<br /> <br /> === PERO ES MUY DIFÍCIL PRODUCIR TODA ESTA DOCUMENTACIÓN… ===<br /> <br /> OWASP no promueve la documentación por la simpre documentación. Este convenio está enfocado en promover la calidad, no la cantidad. Creemos que puede ser posible (en algunos proyectos) cumplir con este contrato con una pequeña evaluación de riesgo, algunas páginas de requerimientos, un pequeño documento de diseño de seguridad, un plan de pruebas, y algunos resultados de pruebas. <br /> <br /> El objetivo de esta documentación es simplemente asegurar, en cada etapa del desarrollo de software, que se ha puesto la atención apropiada en la seguridad. Un beneficio adicional es que esta documentación puede ser recolectada en conjunto para formar un &quot;paquete de certificación&quot; que básicamente esboce el argumento de porque deberiamos confiar que el software hará lo que dice.<br /> <br /> ==ANEXO DE CONTRATO==<br /> <br /> ===1. INTRODUCCIÓN===<br /> <br /> Esta anexo esta hecho para _____________________ (&quot;convenio&quot;) entre el Cliente y el proveedor. Tanto el Cliente como el proveedor acuerdan maximisar la seguridad del software de acuerdo a los siguientes términos.<br /> <br /> <br /> ===2. FILOSOFÍA===<br /> <br /> Esta anexo pretende aclarar los derechos y obligaciones relacionados a seguridad de todas las partes en una relacion de desarrollo de software. Al mayor nivel, las partes acuerdan que:<br /> <br /> ;(a) Las desiciones de seguridad estarán basadas en el riesgo : Las desciciones sobre la seguridad seran tomadas en conunto por el cliente y el proveedor basandose en un firme entendimiento de el riesgo involucrado. <br /> <br /> ;(b) Las actividades de seguridad estarán balanceadas : El esfurzo de seguridad será distribuido equitativamente a través de todo el ciclo de desarollo de software.<br /> <br /> ;(c) Las actividades de seguridad estarán integradas : Todas las actividades y documentación discutidas aqui pueden y deben ser integradas dentro del ciclo de desarrollo de software del proveedor y no mantenerse separadas de el resto del proyecto. Nada en este anexo implica algún processo de desarrollo de software en particular.<br /> <br /> ;(d) Se esperan vulnerabilidades : Todo software contiene defectos, y algunos de estos crearan problemas de seguridad. Ambos, cliente y proveedor se esforzará para identificar las vulnerabilidades tan pronto como sea posible en el ciclo de desarrollo.<br /> <br /> ;(e) La información sobre seguridad será comunicada por completo : Toda la información relevante para la seguridad se compartirá entre el cliente y el proveedor inmediatamente y completamente.<br /> <br /> ;(f) Se requerirá solo documentacion de seguridad necesaria : La documentación de seguridad no necesita ser demasiado amplia para describir claramente el diseño de seguridad, análisis de riesgo y problemas.<br /> <br /> ===3. ACTIVIDADES EN EL CICLO DE DESARROLLO===<br /> <br /> ;(a) Entendimiento del Riesgo : El proveedor y el cliente acuerdan trabajar juntos para entender y documentar los riesgos que enfrenta la aplicacion. Este esfuerzo debe identificar los riesgos clave para los activos y funciones importantes que provee la aplicación. Cada uno de los temas listados en la sección de requerimientos debe ser considerado.<br /> <br /> ;(b) Requerimientos : Basado en los riesgos, El proveedor y cliente acuerda trabajar juntos para crear requerimientos de seguridad detallados como parte de la especificacion de el software a ser desarrollado. Cada uno de los temas listados en la sección de requerimientos de este anexo deben ser discutidos y evaluados por ambos, cliente y proveedor. Estos requerimientos pueden ser satisfechos por software creado a la medida, software de terceros, o la plataforma. <br /> <br /> ;(c) Diseño : el desarollador acuerda proveer documentation que explique claramente el diseño para adquirir cada uno de los requerimientos de seguridad. En muchos de los casos, esta documentacion describirá los mecanismos de seguridad, donde se incluiran dentro de la arquitectura, y todos los patrones de diseño relevantes para asegurar su uso adecuado. El diseño debe especificar claramente si tales mecanismos vienen de software a la medida, software de terceros o de la plataforma.<br /> <br /> ;(d) Implementación : El proveedor acuerda entregar y seguir un conjunto de lineamientos de codificación segura. Estos lineamientos indicarán como sele de debe dar formato, estructurar y comentar el código fuente. Todo código relacionado a seguridad debe ser comentado profundamente. Guías sobre como evitar vulnerabilidades se seguridad comunes debe ser incluida. Tambien, todo el código debe ser revisado por al menos otro desarollador basandose en los requerimientos de seguridad y los lineamientos de codificación antes de ser conciderado listo para pruebas unitarias.<br /> <br /> ;(e) Pruebas y análisis de seguridad : El proveedor acuerda entregar y seguir un plan de pruebas de seguridad que defina como se realizarán las pruebas o bien establecer como cada uno de los requerimientos de seguridad va a ser complido. El nivel de rigor de esta actividad debe ser considerado y detallado en un plan. El proveedor ejecutará el plan de prueba y proveera los resultados a el cliente.<br /> <br /> ;(f) Publicación segura : El proveedor acuerda entregar lineamientos de configuración segura que describan completamente todas las opciones de configuracion relacionadas con seguridad y sus implicaciones para la seguridad del software en su conjunto. Los lineamientos deben incluir una descripción completa de las dependencias en la plataforma y como deben ser configuradas de manera segura, incluidas las del sistema operativo, servidor Web y servidor de aplicacion. La configuracion predeterminada del software debe ser segura.<br /> <br /> ===4. ÁREAS CON REQUERIMIENTOS DE SEGURIDAD===<br /> <br /> Los siguientes temas/áreas deben ser considerados durante las actividades de entendimiento de riesgo y definición de requerimientos. Este esfuerzo debe producir un conjunto de requerimientos ajustados, especificos y probables. Ambos, proveedor y cliente deben ser involucrados en este proceso y deben ponerse de acuerdo sobre el conjunto final de requerimientos.<br /> <br /> ;(a) Validación de entradas y condificación : Los requerimientos deben especificar las reglas para canonicalización, validación y codificación de cada dato de entrada a la aplicación, ya sea de usuarios, sistemas de archivos, bases de datos o sistemas externos. La regla predeterminada debe ser que todas las entradas sean validadas a menos que cumplan con una especificacion detallada de que esta permitido. Además, los requerimientos deben especificar las acciones a tomar cuando se reciven entradas no válidas. Especificamente, la aplicación no debe ser susceptible a inyecciones, desbordamientos, manipulación y otros ataques con entradas de usuario corruptas.<br /> <br /> ;(b) Autentificación y manejo de sessiones : Los requerimientos deben especificar como se protegeran las credenciales para autentificación y los identificadores de sesión a través del ciclo de desarrollo de software. Los requerimientos para todas las funciones relacionadas deben ser agregadas incluyendo recuperar contraseñas, cambio de contraseñas, recordar contraseñas, desconexión y conexión multiple.<br /> <br /> ;(c) Control de Acceso : Los requerimientos deben incluir una descripcion detallada de todos los roles (grupos, privilegios, autorizaciones) usadas en la aplicación. Los requerimientos deben indicar todos los activos y funciones que provee la aplicacion. Los requerimientos deben especificar detallada y exactamente los derechos de acceso para cualquier activo y función de cada rol. Se sugiere utilizar un formato de matriz de control de acceso para documentar estas reglas.<br /> <br /> ;(d) Manejo de Errores : Los requerimientos deben detallar como se van a manejar los errores que ocurran dentro del procesamiento. Algunas aplicaciones deberían hacer lo mejor posible en caso de un error, mientras que otras deberían terminar su procesamiento inmediatamente.<br /> <br /> ;(e) Historial : Los requerimientos deben especificar que eventos son relevantes para la seguridad y necesitan ser registrados, como ataques detectados, intentos de conexión fallidos e intentos de exeder la autorización. Los requerimientos deben especificar tambien que information registrar con cada evento, incluyendo hora y fecha, descripción del evento, detalles de aplicación, y otra información útil en esfuerzos forences.<br /> <br /> ;(f) Conexiones a sistemas externos : Los requerimientos deben especifica como la autentificación y cifrado será manejado para todos los systemas externos, tales como bases de datos, directorios y servicios Web. Todas las credenciales requeridas para la comunicación con sistemas externos deben almacenarce cifradas y fuera de el código dentro de archivos de configuración. <br /> <br /> ;(g) Cifrado : Los requerimientos deben especificar que datos deben ser cifrados, como serán cifrados y como todos los certificados y otras credenciales deben ser manejadas. Las aplicaciones deben usar algoritmos estándar implementados en una librerias de cifrado que hayan sido usadas y probadas ampliamente.<br /> <br /> ;(h) Disponibilidad : Los requerimientos deben especificar como protegerse de ataques de negación de servicio. Todos los posibles ataques en la aplicacion deben ser considerados, incluyendo bloqueos de auntentificación, agotamiento de conexiones y otros ataques de agotamiento de recursos.<br /> <br /> ;(i) Configuración segura : Los requerimientos deben especificar que los valores predeterminados para todas las configuraciones relacionadas a seguridad deben ser seguras. Para propósitos de auditoría, el software deberia ser capás de producir un reporte sencillo de leer que muestre los detalles de todas las configuraciones relacionadas con seguridad.<br /> <br /> ;(j) Vulnerabilidades especificas : Los requerimientos deben incluir un conjunto de vulnerabilidades especificas que no deben estar presentes en el software. A menos que sea especificado de otra manera, el software no debe incluir ninguna de las fallas descritas en el la &quot;Lista de OWASP sobre las 10 vulnerabilidades mas críticas en aplicaciones Web&quot;.<br /> <br /> ===5. PERSONAL Y ORGANIZACIÓN===<br /> <br /> ;(a) Arquitecto en seguridad : El desarollador asignará la responsabilidad por la seguridad a un solo recurso técnico experimentado, para ser conocido como el arquitecto de seguridad del proyecto. El arquitecto de seguridad certificará la seguridad de cada entregable.<br /> <br /> ;(b) Entrenamiento en Seguridad : el proveedor será responsable de verificar que todos los miembros del equipo de desarrollo han sido entrenados en tecnicas de programación segura.<br /> <br /> ;(c) Desarrolladores dignos de confianza : El proveedor acuerda realizar las investigaciones de antecendentes apropiadas a todos los miembros del equipo de desarrollo.<br /> <br /> ===6. AMBIENTE DE DESARROLLO===<br /> <br /> ;(a) Codificación segura : El proveedor debe mencionar que herramientas se usarán en el ambiente de desarrollo de software para promover la codificación segura.<br /> <br /> ;(b) Adminstración de configuración : El proveedor debe usar un sistema de control de versiones que autentifique y registre el miembro del equipo asociado con todos los cambios en el código base, todos los archivos de configuración y compilación.<br /> <br /> ;(c) Distribución : El proveedor debe usar un proceso de compilación que construya confiablemente un archivo de distribución completo desde el código fuente. Este proceso debe incluir un método para verificar la integridad de el software entregado al cliente.<br /> <br /> ===7. LIBRERIAS, MARCOS DE DESARROLLO Y PRODUCTOS===<br /> <br /> ;(a) Apertura : El proveedor debe mencionar todas los aplicaciones de terceros usadas en el software, incluyendo todas las librerias, marcos de desarrollo, componentes y otros productos, ya sean comerciales, gratuitos, de código abierto o código cerrado.<br /> <br /> ;(b) Evaluación : El proveedor debe hacer esfuerzos rasonables para asegurar que el sofware de terceros cumple con todos los términos de este contrato y es tan seguro como el código a la medida desarrollado bajo este contrato.<br /> <br /> ===8. REVISIONES DE SEGURIDAD===<br /> <br /> ;(a) Derecho de revisión : El cliente tiene el derecho mandar revisar el software para buscar fallas de seguridad, esto a sus expesas y en cualquier momento dentro de los 60 dias despues de la entrega. El desarrollador acepta proveer apoyo rasonable al equipo de revisión proveyendo el codigo fuente y acceso a los ambientes de pruebas.<br /> <br /> ;(b) Covertura de la revisión : Las revisiones de seguridad deben cubrir todos los aspectos de el software entregado, incluyendo código a la medida, componentes, productos y configuración de sistema.<br /> <br /> ;(c) Alcance de la revisión : Al menos, la revisión debe cubrir todos los requerimientos de seguridad y debería buscar otras vulnerabilidades comunes. La revisión puede incluir una combinación de busqueda automatizada de vulnerabilidades, pruebas de intrusión, análisis estático de código fuente y revisión de código por expertos.<br /> <br /> ;(d) Problemas encontrados : Los problemas de seguridad descubiertos serán reportados a el cliente y proveedor por igual. A todos los problemas se les dará seguimiento y serán reparados como se especifique en la sección de seguimiento de problemas de seguridad de este anexo.<br /> <br /> ===9. ADMINISTRACIÓN DE PROBLEMAS DE SEGURIDAD===<br /> <br /> ;(a) Identificación : El proveedor dara seguimiento a todos los problemas de seguridad descubiertos en todo el ciclo de desarrollo, ya sea un problema en los requerimientos, diseño, implementación, pruebas, publicación u operación. El riesgo asociado con cada problema de seguridad será evaluado, documentado y reportado a el cliente tan pronto como sea posible.<br /> <br /> ;(b) Protección : El proveedor protegerá apropiadamente la información relacionada a problemas de seguridad y la documentación relacionada a ellos, esto, para ayudar a disminuir la probabilidad de las vulnerabilidades en el software operacioneal del cliente sean expuestas.<br /> <br /> ;(c) Reparación : Los problemas de seguridad que sean indentificados antes de la entrega deben ser reparados por el proveedor. Los problemas de seguridad descubiertos despues de la entrega deben ser manejados en la misma manera que otros problemas funcionales según lo especificado en este contrato.<br /> <br /> ===10. CERTEZA===<br /> <br /> ;(a) Certeza : El proveedor proveera un &quot;paquete de certificación&quot; consistente en la documentación de seguridad creada a traves del proceso de desarrollo. El paquete deberá establecer que los requerimientos de seguridad, diseño, implementación y resultados de pruebas fueron completados apropiadamente y todos los problemas de seguridad fueron resueltos apropiadamente.<br /> <br /> ;(b) Auto-Certificación : El aquitecto de seguridad certificará que el software cumple con los requerimientos de seguridad, que todas las actividades de seguridad se realizaron, y que todos los problemas de seguridad identificados han sido documentados y resueltos. Cualquier excepción a el estado de la certificacion debe estar totalmente documentada al momento de la entrega.<br /> <br /> ;(c) No código malicioso : El proveedor garantize que el sofware no debe contener ningun código que no se alinee a algun requerimiento del software y debilite la seguridad de la aplicación, incluyendo viruses, gusanos, bombas de tiempo, puertas traseras, caballos de troya, huevos de pascua y cualquier otra forma de código malicioso.<br /> <br /> ===11. CONCENTIMIENTO Y MANTENIMIENTO DE LA SEGURIDAD===<br /> <br /> ;(a) Consentimiento : El software no debe ser considerado como aceptado hasta que el paquete de certificación este completo y todos los problemas de seguridad han sido resueltos.<br /> <br /> ;(b) Investigación de problemas de seguridad : Despues del concentimiento, si se sospecha (razonablemente) o descubren problemas de seguridad, el proveedor deberá asisitir al cliente en realizar una investigación para determinar la naturaleza del problema. El problema debe ser considerado &quot;nuevo&quot; si no es cubierto por los requerientos de seguridad y esta fuera de el alcance (razonable) de las pruebas de seguridad.<br /> <br /> ;(c) Problemas de seguridad nuevos : El proveedor y el cliente consientes en medir el alcance y esfuerzo requerido para resolver problemas de seguridad nuevos, y negociad de buena fe para alcanzar un acuerdo y realizar el trabajor requerido para solucionarlos.<br /> <br /> ;(d) Otros problemas de seguridad : El proveedor debe usar todos los esfuersos comercialmente rasonables consistentes con practicas de desarrollo comunes en la industria, tomando en cuenta la severidad de el riesgo, para resolver todos los problemas de seguridad considerados nuevos tan pronto como sea posible.<br /> <br /> [[Category:OWASP Legal Project]]<br /> <br /> __NOTOC__</div>

Jorge Correa https://wiki.owasp.org/index.php?title=Anexo_para_Contrato_de_Software_Seguro_de_OWASP&diff=79726 2010-03-12T13:49:04Z

<p>Jorge Correa: </p> <hr /> <div>'''ANEXO DE CONTRATO PARA DESAROLLO DE SOFTWARE SEGURO'''<br /> <br /> ADVERTENCIA: ESTE DOCUMENTO DEBE SER CONSIDERADO COMO UNA GUÍA SOLAMENTE.<br /> OWASP RECOMIENDA VEHEMENTEMENTE QUE CONSULTE UN ABOGADO CALIFICADO<br /> PARA AYUDARLE A NEGOCIAR UN CONTRATO DE SOFTWARE<br /> <br /> == Introducción ==<br /> <br /> Este anexo de contrato pretende ayudar a los proveedores de software y sus clientes a negociar y capturar importantes términos y condiciones contractuales relacionadas a la seguridad en el Software a ser desarrollado o entregado. La razon para este proyecto es que la mayoría de los contratos no mencionan estos temas, y las partes frecuentamente tienen puntos de vista dramaticamente diferentes a lo que en ralidad fue acordado. Creemos que articular claramente estos términos es la mejor manera de asegurarse que ambas partes pueden hacer desiciones informadas sobre como proceder. <br /> <br /> &quot;La seguridad del software comercial mejorará cuando el mercado demande mejor seguridad.<br /> Al menos, cada petición para propuestas de software debería pedir a los vendedores <br /> detallar como van ellos a probar sus productos para encotrar vulnerabilidades de<br /> seguridad. Este paso empezará convenciendo a los vendedores de software empaquetado<br /> y proveedores externos que las compañias valoran la seguridad.&quot;<br /> <br /> -- John Pescatore, Director de investiagacion con Gartner&lt;br&gt; <br /> <br /> Pedimos a los clientes y proveedores que usen este documento como un marco para discutir<br /> espectativas y negociar responsabilidades. Este anexo se creó para ser añadido a un<br /> contrato de desarrollo de software. Estos términos son negociables, significa que ellos<br /> pueden y deben ser discutidos por el cliente y el proveedor.<br /> <br /> == SOBRE EL PROYECTO ==<br /> <br /> Este documento fue creado por la fundación OWASP (Open Web Application Security Project por sus siglas en Inglés), una organización sin animo de lucro con el objetivo de crear herramientas y documentación, gratuita y abierta para asegurar software. Para facilitar su uso en contratación privada, este documento es de dominio publico. Puede encontrar detalles adicionales sobre este proyecto en http://www.owasp.com/index.php/OWASP_Legal_Project. Son Bienvenidos comentarios de ambos, productores y consumidores de software, asi como de la comunidad legal. <br /> <br /> OWASP reconoce gratamente la contribución especial de [http://www.aspectsecurity.com Aspect Security] por su rol en la investigación y preparación de este documento.<br /> <br /> ==OBJECIONES==<br /> <br /> Las siguientes páginas cubren algunas objeciones que escuchamos frecuentemente sobre usar este lenguaje en contratos de desarrollo de software:<br /> <br /> === PERO NO TODOS LOS TÉRMINOS SON CORRECTOS PARA NOSOTROS… ===<br /> <br /> Este documento debe ser considerado un punto de inicio para su contrato. Puede que no le gusten todas las actividades, o puede querer proponer mas. Puede querer asignar responsabilidades de manera diferente. Este documento no pretende capturar exactamente las necesidades de todos los clientes y proveedores de software. Pretende proveer un marco para discutir temas clave, importantes para asegurarse que el software se cree de forma segura. Despues de que tengan una discusión sobre seguridad y alcancen un acuerdo. Puede ajustar el convenio para que concuerde con el contrato.<br /> <br /> === PERO, ¿QUIEN DEBE PAGAR POR ESTAS ACTIVIDADES?… ===<br /> <br /> Este contrato no es sobre poner mas peso al desarollo de software. La pregunta no es sobre si hay costos asociados con seguridad (por supuesto que hay). La pregunta correcta es qué actividades deberían hacerse por ambas partes para minimizar costos, y cuando deberían ocurrir. <br /> <br /> Este anexo no menciona (intensionalmente) sobre el detalle de quién debería pagar por la actividades descritas. Mientras muchas de estas actividades deben estar pasando ya, y son esperadas por muchos clientes, ellas no estan practicadas regularmente en la industria del software. La cuestion de quién paga (y cuándo) debe ser parte de la negociación. <br /> <br /> Calcular el costo de la seguridad es muy difícil. Auque hay costos asociados con realizar actividades de seguridad, hay también costos importantes asociados con ignorar estas actividades. Estamos convencidos el mejor costo-beneficio para desarrollar software es reducir la probabilidad de que fallas de seguridad sean introducidas y minimzar el tiempo entre introducir una falla y arreglarla. <br /> <br /> Una distición importante a hacer cuando calculamos costos es entre construir mecanismos de seguridad y las actividades para asegurarse que esos mecanismos sean correctos y efectivos. Intentar agregar mecanismoa al final de el ciclo de desarrollo puede causar serios problemas de diseño e incrementará el costo dramáticamente. Este convenio promueve decisiones sobre mecanismos para minimizar estos costos. Similarmente, esperar hasta justo antes de la puesta en producción para hacer actividades de aseguramiento, tales como revisión de código y pruebas de intrusión, tambien incrementaría los costos dramaticamente. Creemos que el mejor costo-beneficio para ganar certeza es poner un nivel constante de esfuerzo en el aseguramiento a través del ciclo de desarrollo.<br /> <br /> === PERO EL NIVEL DE RIGOR ESTA INCORRECTO…. ===<br /> <br /> Este convenio asume que el software que esta siendo desarrollado es razonablemente importante para una empresa grande o agencia de gobierno. Hemos seleccionado un &quot;nivel de rigor&quot; para el convenio que es alcanzable por la mayoria de las organizaciones proveedoras de software, e identificaría y manejaría los riesgos más comunes. <br /> <br /> Sin embargo, para el software que va a ser usado en aplicaciones críticas, como aplicaciones médicas, financieras o relacionadas con el ejército. Puede querer incrementar el nivel de rigor. Puede querer agregar revisiones, documentación y actividades adicionales de prueba. Puede querer mejorar el proceso de encontrar, diagnosticar y remediar vulnerabilidades. Para aplicaciones menos sensibles, puede desear reducir o remover actividades.<br /> <br /> === PERO NOSOTROS NO PODEMOS ACEPTAR TANTO RIESGO… ===<br /> <br /> Este convenio pretende facilitar la discusión sobre quién tomaría el riesgo por las vulnerabilidades de seguridad en el software. Por un lado del espectro, el cliente podría tomar todo el riesgo y el proveedor podría entregar código con muchas vulnerabilidades. Por el otro extremo, el proveedor podría tomar todo el riesgo y asumir la responsabilidad de entregar código perfecto. Ambos extremos son irrealizables. <br /> <br /> Actualmente, en este convenio, el proveedor toma el riesgo por problemas que sean descubiertos en los requerimientos o deben ser cubiertos por esfuerzos razonables en pruebas. Pero la remediación de &quot;nuevos&quot; problemas de seguridad tendría que ser pagado por el cliente. Creemos que este es un equilibrio funcional, ya que limita el riesgo adquirido por el proveedor y promueve obtener requerimientos de seguridad por anticipado. Pero hay muchas otras posibles soluciones a este problema. Por favor, dejenos saber si tiene sugerencias alternas, podriamos incluirlas en versiones futuras de este documento. <br /> <br /> Note que la discusión aqui solo cubre el riesgo asociado con arreglar las vulnerabilidades de seguridad en el código, y no incluye los costos asociados con recuperarse de incidentes de seguridad relacionados con explotar cualquiera de esas vulnerabilidades. Estamos interesados en las mejores prácticas en esta area.<br /> <br /> === PERO COMO PODEMOS ASEGURAR CÓDIGO DE TERCEROS… ===<br /> <br /> Casi todos los proyectos de sofware tienen una cantidad importante de código de terceros como librerias, frameworks y productos. Desde la perspectiva de seguridad, este código es tan importante como el código desarrollado a la medida para su proyecto. Creemos que la responsabilidad de garantizar la seguridad de este código es llevada mejor por el proveedor, aunque ellos podrían no tener toda la capacidad para garantizar la seguridad por ellos mismos. Sin embargo, la seguridad puede ser parte de el la desición de &quot;construir o comprar&quot;, y esta parece ser la mejor manera de promoverla. <br /> <br /> El proveedor, por supuesto, tiene la opción de pasar la responsabilidad al proveedor del software de terceros. El desarrollador puede también analizar el código de terceros por él mismo o contratar expertos en seguridad para analizarlo por él.<br /> <br /> === PERO PORQUE DEBO PASAR POR TODO ESTE PROBLEMA… ===<br /> <br /> En última instancia, creemos que no hay alternativa para hacer de la seguridad una parte de el proceso de contratación de software. Actualmente, creemos que hay serios malentendidos sobre la seguridad del código que esta siendo desarrollado bajo muchos contratos de desarrollo de software. Esto puede solamente llevar a una cara litigación y a desiciones hechas por individuos con poca experiencia y entendimiento sobre software. Lea el [[Secure software contracting hypothetical case study|Caso de estudio hipotético sobre contratación de software seguro]] para una discusión completa de este problema. <br /> <br /> Hay muchos beneficios al trabajar con este convenio. El principal es que pondrá claras las expectativas entre las partes involucradas. En algunos casos ayudará a evitar demandas cuando problemas de seguridad difíciles aparecen en el software. Tambien, estas son las mismas actividades requeridas por muchas razónes legales y de conformidad con estándares/leyes.<br /> <br /> ===PERO ES MUY DIFÍCIL PRODUCIR TODA ESTA DOCUMENTACIÓN…===<br /> <br /> OWASP no promueve la documentacion por la simpre documentacion. Este convenio esta enfocado en promover la calidad, no la cantidad. Creemos que puede ser posible (en algunos proyectos) cumplir con este contrato con una pequeña evaluacion de riesgo, algunas páginas de requerimientos, un pequeño documento de diseño de seguridad, un plan de pruebas, y algunos resultados de pruebas.<br /> <br /> El objetivo de esta documentación es simplemente asegurar, en cada etapa del desarrollo de software, que se ha puesto la atención apropiada en la seguridad. Un beneficio adiciona es que esta documentacion puede ser recolectada en conjunto para formar un &quot;paquete de certificación&quot; que básicamente esbose el argumento de porque deberiamos confiar que el software hará lo que dice.<br /> <br /> ==ANEXO DE CONTRATO==<br /> <br /> ===1. INTRODUCCIÓN===<br /> <br /> Esta anexo esta hecho para _____________________ (&quot;convenio&quot;) entre el Cliente y el proveedor. Tanto el Cliente como el proveedor acuerdan maximisar la seguridad del software de acuerdo a los siguientes términos.<br /> <br /> <br /> ===2. FILOSOFÍA===<br /> <br /> Esta anexo pretende aclarar los derechos y obligaciones relacionados a seguridad de todas las partes en una relacion de desarrollo de software. Al mayor nivel, las partes acuerdan que:<br /> <br /> ;(a) Las desiciones de seguridad estarán basadas en el riesgo : Las desciciones sobre la seguridad seran tomadas en conunto por el cliente y el proveedor basandose en un firme entendimiento de el riesgo involucrado. <br /> <br /> ;(b) Las actividades de seguridad estarán balanceadas : El esfurzo de seguridad será distribuido equitativamente a través de todo el ciclo de desarollo de software.<br /> <br /> ;(c) Las actividades de seguridad estarán integradas : Todas las actividades y documentación discutidas aqui pueden y deben ser integradas dentro del ciclo de desarrollo de software del proveedor y no mantenerse separadas de el resto del proyecto. Nada en este anexo implica algún processo de desarrollo de software en particular.<br /> <br /> ;(d) Se esperan vulnerabilidades : Todo software contiene defectos, y algunos de estos crearan problemas de seguridad. Ambos, cliente y proveedor se esforzará para identificar las vulnerabilidades tan pronto como sea posible en el ciclo de desarrollo.<br /> <br /> ;(e) La información sobre seguridad será comunicada por completo : Toda la información relevante para la seguridad se compartirá entre el cliente y el proveedor inmediatamente y completamente.<br /> <br /> ;(f) Se requerirá solo documentacion de seguridad necesaria : La documentación de seguridad no necesita ser demasiado amplia para describir claramente el diseño de seguridad, análisis de riesgo y problemas.<br /> <br /> ===3. ACTIVIDADES EN EL CICLO DE DESARROLLO===<br /> <br /> ;(a) Entendimiento del Riesgo : El proveedor y el cliente acuerdan trabajar juntos para entender y documentar los riesgos que enfrenta la aplicacion. Este esfuerzo debe identificar los riesgos clave para los activos y funciones importantes que provee la aplicación. Cada uno de los temas listados en la sección de requerimientos debe ser considerado.<br /> <br /> ;(b) Requerimientos : Basado en los riesgos, El proveedor y cliente acuerda trabajar juntos para crear requerimientos de seguridad detallados como parte de la especificacion de el software a ser desarrollado. Cada uno de los temas listados en la sección de requerimientos de este anexo deben ser discutidos y evaluados por ambos, cliente y proveedor. Estos requerimientos pueden ser satisfechos por software creado a la medida, software de terceros, o la plataforma. <br /> <br /> ;(c) Diseño : el desarollador acuerda proveer documentation que explique claramente el diseño para adquirir cada uno de los requerimientos de seguridad. En muchos de los casos, esta documentacion describirá los mecanismos de seguridad, donde se incluiran dentro de la arquitectura, y todos los patrones de diseño relevantes para asegurar su uso adecuado. El diseño debe especificar claramente si tales mecanismos vienen de software a la medida, software de terceros o de la plataforma.<br /> <br /> ;(d) Implementación : El proveedor acuerda entregar y seguir un conjunto de lineamientos de codificación segura. Estos lineamientos indicarán como sele de debe dar formato, estructurar y comentar el código fuente. Todo código relacionado a seguridad debe ser comentado profundamente. Guías sobre como evitar vulnerabilidades se seguridad comunes debe ser incluida. Tambien, todo el código debe ser revisado por al menos otro desarollador basandose en los requerimientos de seguridad y los lineamientos de codificación antes de ser conciderado listo para pruebas unitarias.<br /> <br /> ;(e) Pruebas y análisis de seguridad : El proveedor acuerda entregar y seguir un plan de pruebas de seguridad que defina como se realizarán las pruebas o bien establecer como cada uno de los requerimientos de seguridad va a ser complido. El nivel de rigor de esta actividad debe ser considerado y detallado en un plan. El proveedor ejecutará el plan de prueba y proveera los resultados a el cliente.<br /> <br /> ;(f) Publicación segura : El proveedor acuerda entregar lineamientos de configuración segura que describan completamente todas las opciones de configuracion relacionadas con seguridad y sus implicaciones para la seguridad del software en su conjunto. Los lineamientos deben incluir una descripción completa de las dependencias en la plataforma y como deben ser configuradas de manera segura, incluidas las del sistema operativo, servidor Web y servidor de aplicacion. La configuracion predeterminada del software debe ser segura.<br /> <br /> ===4. ÁREAS CON REQUERIMIENTOS DE SEGURIDAD===<br /> <br /> Los siguientes temas/áreas deben ser considerados durante las actividades de entendimiento de riesgo y definición de requerimientos. Este esfuerzo debe producir un conjunto de requerimientos ajustados, especificos y probables. Ambos, proveedor y cliente deben ser involucrados en este proceso y deben ponerse de acuerdo sobre el conjunto final de requerimientos.<br /> <br /> ;(a) Validación de entradas y condificación : Los requerimientos deben especificar las reglas para canonicalización, validación y codificación de cada dato de entrada a la aplicación, ya sea de usuarios, sistemas de archivos, bases de datos o sistemas externos. La regla predeterminada debe ser que todas las entradas sean validadas a menos que cumplan con una especificacion detallada de que esta permitido. Además, los requerimientos deben especificar las acciones a tomar cuando se reciven entradas no válidas. Especificamente, la aplicación no debe ser susceptible a inyecciones, desbordamientos, manipulación y otros ataques con entradas de usuario corruptas.<br /> <br /> ;(b) Autentificación y manejo de sessiones : Los requerimientos deben especificar como se protegeran las credenciales para autentificación y los identificadores de sesión a través del ciclo de desarrollo de software. Los requerimientos para todas las funciones relacionadas deben ser agregadas incluyendo recuperar contraseñas, cambio de contraseñas, recordar contraseñas, desconexión y conexión multiple.<br /> <br /> ;(c) Control de Acceso : Los requerimientos deben incluir una descripcion detallada de todos los roles (grupos, privilegios, autorizaciones) usadas en la aplicación. Los requerimientos deben indicar todos los activos y funciones que provee la aplicacion. Los requerimientos deben especificar detallada y exactamente los derechos de acceso para cualquier activo y función de cada rol. Se sugiere utilizar un formato de matriz de control de acceso para documentar estas reglas.<br /> <br /> ;(d) Manejo de Errores : Los requerimientos deben detallar como se van a manejar los errores que ocurran dentro del procesamiento. Algunas aplicaciones deberían hacer lo mejor posible en caso de un error, mientras que otras deberían terminar su procesamiento inmediatamente.<br /> <br /> ;(e) Historial : Los requerimientos deben especificar que eventos son relevantes para la seguridad y necesitan ser registrados, como ataques detectados, intentos de conexión fallidos e intentos de exeder la autorización. Los requerimientos deben especificar tambien que information registrar con cada evento, incluyendo hora y fecha, descripción del evento, detalles de aplicación, y otra información útil en esfuerzos forences.<br /> <br /> ;(f) Conexiones a sistemas externos : Los requerimientos deben especifica como la autentificación y cifrado será manejado para todos los systemas externos, tales como bases de datos, directorios y servicios Web. Todas las credenciales requeridas para la comunicación con sistemas externos deben almacenarce cifradas y fuera de el código dentro de archivos de configuración. <br /> <br /> ;(g) Cifrado : Los requerimientos deben especificar que datos deben ser cifrados, como serán cifrados y como todos los certificados y otras credenciales deben ser manejadas. Las aplicaciones deben usar algoritmos estándar implementados en una librerias de cifrado que hayan sido usadas y probadas ampliamente.<br /> <br /> ;(h) Disponibilidad : Los requerimientos deben especificar como protegerse de ataques de negación de servicio. Todos los posibles ataques en la aplicacion deben ser considerados, incluyendo bloqueos de auntentificación, agotamiento de conexiones y otros ataques de agotamiento de recursos.<br /> <br /> ;(i) Configuración segura : Los requerimientos deben especificar que los valores predeterminados para todas las configuraciones relacionadas a seguridad deben ser seguras. Para propósitos de auditoría, el software deberia ser capás de producir un reporte sencillo de leer que muestre los detalles de todas las configuraciones relacionadas con seguridad.<br /> <br /> ;(j) Vulnerabilidades especificas : Los requerimientos deben incluir un conjunto de vulnerabilidades especificas que no deben estar presentes en el software. A menos que sea especificado de otra manera, el software no debe incluir ninguna de las fallas descritas en el la &quot;Lista de OWASP sobre las 10 vulnerabilidades mas críticas en aplicaciones Web&quot;.<br /> <br /> ===5. PERSONAL Y ORGANIZACIÓN===<br /> <br /> ;(a) Arquitecto en seguridad : El desarollador asignará la responsabilidad por la seguridad a un solo recurso técnico experimentado, para ser conocido como el arquitecto de seguridad del proyecto. El arquitecto de seguridad certificará la seguridad de cada entregable.<br /> <br /> ;(b) Entrenamiento en Seguridad : el proveedor será responsable de verificar que todos los miembros del equipo de desarrollo han sido entrenados en tecnicas de programación segura.<br /> <br /> ;(c) Desarrolladores dignos de confianza : El proveedor acuerda realizar las investigaciones de antecendentes apropiadas a todos los miembros del equipo de desarrollo.<br /> <br /> ===6. AMBIENTE DE DESARROLLO===<br /> <br /> ;(a) Codificación segura : El proveedor debe mencionar que herramientas se usarán en el ambiente de desarrollo de software para promover la codificación segura.<br /> <br /> ;(b) Adminstración de configuración : El proveedor debe usar un sistema de control de versiones que autentifique y registre el miembro del equipo asociado con todos los cambios en el código base, todos los archivos de configuración y compilación.<br /> <br /> ;(c) Distribución : El proveedor debe usar un proceso de compilación que construya confiablemente un archivo de distribución completo desde el código fuente. Este proceso debe incluir un método para verificar la integridad de el software entregado al cliente.<br /> <br /> ===7. LIBRERIAS, MARCOS DE DESARROLLO Y PRODUCTOS===<br /> <br /> ;(a) Apertura : El proveedor debe mencionar todas los aplicaciones de terceros usadas en el software, incluyendo todas las librerias, marcos de desarrollo, componentes y otros productos, ya sean comerciales, gratuitos, de código abierto o código cerrado.<br /> <br /> ;(b) Evaluación : El proveedor debe hacer esfuerzos rasonables para asegurar que el sofware de terceros cumple con todos los términos de este contrato y es tan seguro como el código a la medida desarrollado bajo este contrato.<br /> <br /> ===8. REVISIONES DE SEGURIDAD===<br /> <br /> ;(a) Derecho de revisión : El cliente tiene el derecho mandar revisar el software para buscar fallas de seguridad, esto a sus expesas y en cualquier momento dentro de los 60 dias despues de la entrega. El desarrollador acepta proveer apoyo rasonable al equipo de revisión proveyendo el codigo fuente y acceso a los ambientes de pruebas.<br /> <br /> ;(b) Covertura de la revisión : Las revisiones de seguridad deben cubrir todos los aspectos de el software entregado, incluyendo código a la medida, componentes, productos y configuración de sistema.<br /> <br /> ;(c) Alcance de la revisión : Al menos, la revisión debe cubrir todos los requerimientos de seguridad y debería buscar otras vulnerabilidades comunes. La revisión puede incluir una combinación de busqueda automatizada de vulnerabilidades, pruebas de intrusión, análisis estático de código fuente y revisión de código por expertos.<br /> <br /> ;(d) Problemas encontrados : Los problemas de seguridad descubiertos serán reportados a el cliente y proveedor por igual. A todos los problemas se les dará seguimiento y serán reparados como se especifique en la sección de seguimiento de problemas de seguridad de este anexo.<br /> <br /> ===9. ADMINISTRACIÓN DE PROBLEMAS DE SEGURIDAD===<br /> <br /> ;(a) Identificación : El proveedor dara seguimiento a todos los problemas de seguridad descubiertos en todo el ciclo de desarrollo, ya sea un problema en los requerimientos, diseño, implementación, pruebas, publicación u operación. El riesgo asociado con cada problema de seguridad será evaluado, documentado y reportado a el cliente tan pronto como sea posible.<br /> <br /> ;(b) Protección : El proveedor protegerá apropiadamente la información relacionada a problemas de seguridad y la documentación relacionada a ellos, esto, para ayudar a disminuir la probabilidad de las vulnerabilidades en el software operacioneal del cliente sean expuestas.<br /> <br /> ;(c) Reparación : Los problemas de seguridad que sean indentificados antes de la entrega deben ser reparados por el proveedor. Los problemas de seguridad descubiertos despues de la entrega deben ser manejados en la misma manera que otros problemas funcionales según lo especificado en este contrato.<br /> <br /> ===10. CERTEZA===<br /> <br /> ;(a) Certeza : El proveedor proveera un &quot;paquete de certificación&quot; consistente en la documentación de seguridad creada a traves del proceso de desarrollo. El paquete deberá establecer que los requerimientos de seguridad, diseño, implementación y resultados de pruebas fueron completados apropiadamente y todos los problemas de seguridad fueron resueltos apropiadamente.<br /> <br /> ;(b) Auto-Certificación : El aquitecto de seguridad certificará que el software cumple con los requerimientos de seguridad, que todas las actividades de seguridad se realizaron, y que todos los problemas de seguridad identificados han sido documentados y resueltos. Cualquier excepción a el estado de la certificacion debe estar totalmente documentada al momento de la entrega.<br /> <br /> ;(c) No código malicioso : El proveedor garantize que el sofware no debe contener ningun código que no se alinee a algun requerimiento del software y debilite la seguridad de la aplicación, incluyendo viruses, gusanos, bombas de tiempo, puertas traseras, caballos de troya, huevos de pascua y cualquier otra forma de código malicioso.<br /> <br /> ===11. CONCENTIMIENTO Y MANTENIMIENTO DE LA SEGURIDAD===<br /> <br /> ;(a) Consentimiento : El software no debe ser considerado como aceptado hasta que el paquete de certificación este completo y todos los problemas de seguridad han sido resueltos.<br /> <br /> ;(b) Investigación de problemas de seguridad : Despues del concentimiento, si se sospecha (razonablemente) o descubren problemas de seguridad, el proveedor deberá asisitir al cliente en realizar una investigación para determinar la naturaleza del problema. El problema debe ser considerado &quot;nuevo&quot; si no es cubierto por los requerientos de seguridad y esta fuera de el alcance (razonable) de las pruebas de seguridad.<br /> <br /> ;(c) Problemas de seguridad nuevos : El proveedor y el cliente consientes en medir el alcance y esfuerzo requerido para resolver problemas de seguridad nuevos, y negociad de buena fe para alcanzar un acuerdo y realizar el trabajor requerido para solucionarlos.<br /> <br /> ;(d) Otros problemas de seguridad : El proveedor debe usar todos los esfuersos comercialmente rasonables consistentes con practicas de desarrollo comunes en la industria, tomando en cuenta la severidad de el riesgo, para resolver todos los problemas de seguridad considerados nuevos tan pronto como sea posible.<br /> <br /> [[Category:OWASP Legal Project]]<br /> <br /> __NOTOC__</div>

Jorge Correa https://wiki.owasp.org/index.php?title=Anexo_para_Contrato_de_Software_Seguro_de_OWASP&diff=79725 2010-03-12T13:47:54Z

<p>Jorge Correa: </p> <hr /> <div>'''ANEXO DE CONTRATO PARA DESAROLLO DE SOFTWARE SEGURO'''<br /> <br /> ADVERTENCIA: ESTE DOCUMENTO DEBE SER CONSIDERADO COMO UNA GUÍA SOLAMENTE.<br /> OWASP RECOMIENDA VEHEMENTEMENTE QUE CONSULTE UN ABOGADO CALIFICADO<br /> PARA AYUDARLE A NEGOCIAR UN CONTRATO DE SOFTWARE<br /> <br /> == Introducción ==<br /> <br /> Este anexo de contrato pretende ayudar a los proveedores de software y sus clientes a negociar y capturar importantes términos y condiciones contractuales relacionadas a la seguridad en el Software a ser desarrollado o entregado. La razon para este proyecto es que la mayoría de los contratos no mencionan estos temas, y las partes frecuentamente tienen puntos de vista dramaticamente diferentes a lo que en ralidad fue acordado. Creemos que articular claramente estos términos es la mejor manera de asegurarse que ambas partes pueden hacer desiciones informadas sobre como proceder. <br /> <br /> &quot;La seguridad del software comercial mejorará cuando el mercado demande mejor seguridad.<br /> Al menos, cada petición para propuestas de software debería pedir a los vendedores <br /> detallar como van ellos a probar sus productos para encotrar vulnerabilidades de<br /> seguridad. Este paso empezará convenciendo a los vendedores de software empaquetado<br /> y proveedores externos que las compañias valoran la seguridad.&quot;<br /> <br /> -- John Pescatore, Director de investiagacion con Gartner&lt;br&gt; <br /> <br /> Pedimos a los clientes y proveedores que usen este documento como un marco para discutir<br /> espectativas y negociar responsabilidades. Este anexo se creó para ser añadido a un<br /> contrato de desarrollo de software. Estos términos son negociables, significa que ellos<br /> pueden y deben ser discutidos por el cliente y el proveedor.<br /> <br /> == SOBRE EL PROYECTO ==<br /> <br /> Este documento fue creado por la fundación OWASP (Open Web Application Security Project por sus siglas en Inglés), una organización sin animo de lucro con el objetivo de crear herramientas y documentación, gratuita y abierta para asegurar software. Para facilitar su uso en contratación privada, este documento es de dominio publico. Puede encontrar detalles adicionales sobre este proyecto en http://www.owasp.com/index.php/OWASP_Legal_Project. Son Bienvenidos comentarios de ambos, productores y consumidores de software, asi como de la comunidad legal. <br /> <br /> OWASP reconoce gratamente la contribución especial de [http://www.aspectsecurity.com Aspect Security] por su rol en la investigación y preparación de este documento.<br /> <br /> ==OBJECIONES==<br /> <br /> Las siguientes páginas cubren algunas objeciones que escuchamos frecuentemente sobre usar este lenguaje en contratos de desarrollo de software:<br /> <br /> === PERO NO TODOS LOS TÉRMINOS SON CORRECTOS PARA NOSOTROS… ===<br /> <br /> Este documento debe ser considerado un punto de inicio para su contrato. Puede que no le gusten todas las actividades, o puede querer proponer mas. Puede querer asignar responsabilidades de manera diferente. Este documento no pretende capturar exactamente las necesidades de todos los clientes y proveedores de software. Pretende proveer un marco para discutir temas clave, importantes para asegurarse que el software se cree de forma segura. Despues de que tengan una discusión sobre seguridad y alcancen un acuerdo. Puede ajustar el convenio para que concuerde con el contrato.<br /> <br /> === PERO, ¿QUIEN DEBE PAGAR POR ESTAS ACTIVIDADES?… ===<br /> <br /> Este contrato no es sobre poner mas peso al desarollo de software. La pregunta no es sobre si hay costos asociados con seguridad (por supuesto que hay). La pregunta correcta es qué actividades deberían hacerse por ambas partes para minimizar costos, y cuando deberían ocurrir. <br /> <br /> Este anexo no menciona (intensionalmente) sobre el detalle de quién debería pagar por la actividades descritas. Mientras muchas de estas actividades deben estar pasando ya, y son esperadas por muchos clientes, ellas no estan practicadas regularmente en la industria del software. La cuestion de quién paga (y cuándo) debe ser parte de la negociación. <br /> <br /> Calcular el costo de la seguridad es muy difícil. Auque hay costos asociados con realizar actividades de seguridad, hay también costos importantes asociados con ignorar estas actividades. Estamos convencidos el mejor costo-beneficio para desarrollar software es reducir la probabilidad de que fallas de seguridad sean introducidas y minimzar el tiempo entre introducir una falla y arreglarla. <br /> <br /> Una distición importante a hacer cuando calculamos costos es entre construir mecanismos de seguridad y las actividades para asegurarse que esos mecanismos sean correctos y efectivos. Intentar agregar mecanismoa al final de el ciclo de desarrollo puede causar serios problemas de diseño e incrementará el costo dramáticamente. Este convenio promueve decisiones sobre mecanismos para minimizar estos costos. Similarmente, esperar hasta justo antes de la puesta en producción para hacer actividades de aseguramiento, tales como revisión de código y pruebas de intrusión, tambien incrementaría los costos dramaticamente. Creemos que el mejor costo-beneficio para ganar certeza es poner un nivel constante de esfuerzo en el aseguramiento a través del ciclo de desarrollo.<br /> <br /> === PERO EL NIVEL DE RIGOR ESTA INCORRECTO…. ===<br /> <br /> Este convenio asume que el software que esta siendo desarrollado es razonablemente importante para una empresa grande o agencia de gobierno. Hemos seleccionado un &quot;nivel de rigor&quot; para el convenio que es alcanzable por la mayoria de las organizaciones proveedoras de software, e identificaría y manejaría los riesgos más comunes. <br /> <br /> Sin embargo, para el software que va a ser usado en aplicaciones críticas, como aplicaciones médicas, financieras o relacionadas con el ejército. Puede querer incrementar el nivel de rigor. Puede querer agregar revisiones, documentación y actividades adicionales de prueba. Puede querer mejorar el proceso de encontrar, diagnosticar y remediar vulnerabilidades. Para aplicaciones menos sensibles, puede desear reducir o remover actividades.<br /> <br /> === PERO NOSOTROS NO PODEMOS ACEPTAR TANTO RIESGO… ===<br /> <br /> Este convenio pretende facilitar la discusión sobre quién tomaría el riesgo por las vulnerabilidades de seguridad en el software. Por un lado del espectro, el cliente podría tomar todo el riesgo y el proveedor podría entregar código con muchas vulnerabilidades. Por el otro extremo, el proveedor podría tomar todo el riesgo y asumir la responsabilidad de entregar código perfecto. Ambos extremos son irrealizables. <br /> <br /> Actualmente, en este convenio, el proveedor toma el riesgo por problemas que sean descubiertos en los requerimientos o deben ser cubiertos por esfuerzos razonables en pruebas. Pero la remediación de &quot;nuevos&quot; problemas de seguridad tendría que ser pagado por el cliente. Creemos que este es un equilibrio funcional, ya que limita el riesgo adquirido por el proveedor y promueve obtener requerimientos de seguridad por anticipado. Pero hay muchas otras posibles soluciones a este problema. Por favor, dejenos saber si tiene sugerencias alternas, podriamos incluirlas en versiones futuras de este documento. <br /> <br /> Note que la discusión aqui solo cubre el riesgo asociado con arreglar las vulnerabilidades de seguridad en el código, y no incluye los costos asociados con recuperarse de incidentes de seguridad relacionados con explotar cualquiera de esas vulnerabilidades. Estamos interesados en las mejores prácticas en esta area.<br /> <br /> === PERO COMO PODEMOS ASEGURAR CÓDIGO DE TERCEROS… ===<br /> <br /> Casi todos los proyectos de sofware tienen una cantidad importante de código de terceros como librerias, frameworks y productos. Desde la perspectiva de seguridad, este código es tan importante como el código desarrollado a la medida para su proyecto. Creemos que la responsabilidad de garantizar la seguridad de este código es llevada mejor por el proveedor, aunque ellos podrían no tener toda la capacidad para garantizar la seguridad por ellos mismos. Sin embargo, la seguridad puede ser parte de el la desición de &quot;construir o comprar&quot;, y esta parece ser la mejor manera de promoverla. <br /> <br /> El proveedor, por supuesto, tiene la opción de pasar la responsabilidad al proveedor del software de terceros. El desarrollador puede también analizar el código de terceros por él mismo o contratar expertos en seguridad para analizarlo por él.<br /> <br /> ===PERO PORQUE DEBO PASAR POR TODO ESTE PROBLEMA…===<br /> <br /> En última instancia, creemos que no hay alternativa para hacer de la seguridad una parte de el proceso de contratación de software. Actualmente, creemos que hay serios malentendidos sobre la seguridad del código que esta siendo desarrollado bajo muchos contratos de desarrollo de software. Esto puede solamente llevar a una cara litigación y a desiciones hechas por individuos con poca experiencia y entendimiento sobre software. Lea el [[Secure software contracting hypothetical case study | Caso de estudio hipotético sobre contratación de software seguro]] para una discusión completa de este problema.<br /> <br /> Hay muchos beneficios al trabajar con este convenio. El principal es que pondrá claras las expectativas entre las partes involucradas. En algunos casos ayudará a evitar demandas cuando problemas de seguridad difíciles aparecen en el software. Tambien, estan son las mismas actividades requeridas por muchas razónes legales y de conformidad con estándares/leyes.<br /> <br /> ===PERO ES MUY DIFÍCIL PRODUCIR TODA ESTA DOCUMENTACIÓN…===<br /> <br /> OWASP no promueve la documentacion por la simpre documentacion. Este convenio esta enfocado en promover la calidad, no la cantidad. Creemos que puede ser posible (en algunos proyectos) cumplir con este contrato con una pequeña evaluacion de riesgo, algunas páginas de requerimientos, un pequeño documento de diseño de seguridad, un plan de pruebas, y algunos resultados de pruebas.<br /> <br /> El objetivo de esta documentación es simplemente asegurar, en cada etapa del desarrollo de software, que se ha puesto la atención apropiada en la seguridad. Un beneficio adiciona es que esta documentacion puede ser recolectada en conjunto para formar un &quot;paquete de certificación&quot; que básicamente esbose el argumento de porque deberiamos confiar que el software hará lo que dice.<br /> <br /> ==ANEXO DE CONTRATO==<br /> <br /> ===1. INTRODUCCIÓN===<br /> <br /> Esta anexo esta hecho para _____________________ (&quot;convenio&quot;) entre el Cliente y el proveedor. Tanto el Cliente como el proveedor acuerdan maximisar la seguridad del software de acuerdo a los siguientes términos.<br /> <br /> <br /> ===2. FILOSOFÍA===<br /> <br /> Esta anexo pretende aclarar los derechos y obligaciones relacionados a seguridad de todas las partes en una relacion de desarrollo de software. Al mayor nivel, las partes acuerdan que:<br /> <br /> ;(a) Las desiciones de seguridad estarán basadas en el riesgo : Las desciciones sobre la seguridad seran tomadas en conunto por el cliente y el proveedor basandose en un firme entendimiento de el riesgo involucrado. <br /> <br /> ;(b) Las actividades de seguridad estarán balanceadas : El esfurzo de seguridad será distribuido equitativamente a través de todo el ciclo de desarollo de software.<br /> <br /> ;(c) Las actividades de seguridad estarán integradas : Todas las actividades y documentación discutidas aqui pueden y deben ser integradas dentro del ciclo de desarrollo de software del proveedor y no mantenerse separadas de el resto del proyecto. Nada en este anexo implica algún processo de desarrollo de software en particular.<br /> <br /> ;(d) Se esperan vulnerabilidades : Todo software contiene defectos, y algunos de estos crearan problemas de seguridad. Ambos, cliente y proveedor se esforzará para identificar las vulnerabilidades tan pronto como sea posible en el ciclo de desarrollo.<br /> <br /> ;(e) La información sobre seguridad será comunicada por completo : Toda la información relevante para la seguridad se compartirá entre el cliente y el proveedor inmediatamente y completamente.<br /> <br /> ;(f) Se requerirá solo documentacion de seguridad necesaria : La documentación de seguridad no necesita ser demasiado amplia para describir claramente el diseño de seguridad, análisis de riesgo y problemas.<br /> <br /> ===3. ACTIVIDADES EN EL CICLO DE DESARROLLO===<br /> <br /> ;(a) Entendimiento del Riesgo : El proveedor y el cliente acuerdan trabajar juntos para entender y documentar los riesgos que enfrenta la aplicacion. Este esfuerzo debe identificar los riesgos clave para los activos y funciones importantes que provee la aplicación. Cada uno de los temas listados en la sección de requerimientos debe ser considerado.<br /> <br /> ;(b) Requerimientos : Basado en los riesgos, El proveedor y cliente acuerda trabajar juntos para crear requerimientos de seguridad detallados como parte de la especificacion de el software a ser desarrollado. Cada uno de los temas listados en la sección de requerimientos de este anexo deben ser discutidos y evaluados por ambos, cliente y proveedor. Estos requerimientos pueden ser satisfechos por software creado a la medida, software de terceros, o la plataforma. <br /> <br /> ;(c) Diseño : el desarollador acuerda proveer documentation que explique claramente el diseño para adquirir cada uno de los requerimientos de seguridad. En muchos de los casos, esta documentacion describirá los mecanismos de seguridad, donde se incluiran dentro de la arquitectura, y todos los patrones de diseño relevantes para asegurar su uso adecuado. El diseño debe especificar claramente si tales mecanismos vienen de software a la medida, software de terceros o de la plataforma.<br /> <br /> ;(d) Implementación : El proveedor acuerda entregar y seguir un conjunto de lineamientos de codificación segura. Estos lineamientos indicarán como sele de debe dar formato, estructurar y comentar el código fuente. Todo código relacionado a seguridad debe ser comentado profundamente. Guías sobre como evitar vulnerabilidades se seguridad comunes debe ser incluida. Tambien, todo el código debe ser revisado por al menos otro desarollador basandose en los requerimientos de seguridad y los lineamientos de codificación antes de ser conciderado listo para pruebas unitarias.<br /> <br /> ;(e) Pruebas y análisis de seguridad : El proveedor acuerda entregar y seguir un plan de pruebas de seguridad que defina como se realizarán las pruebas o bien establecer como cada uno de los requerimientos de seguridad va a ser complido. El nivel de rigor de esta actividad debe ser considerado y detallado en un plan. El proveedor ejecutará el plan de prueba y proveera los resultados a el cliente.<br /> <br /> ;(f) Publicación segura : El proveedor acuerda entregar lineamientos de configuración segura que describan completamente todas las opciones de configuracion relacionadas con seguridad y sus implicaciones para la seguridad del software en su conjunto. Los lineamientos deben incluir una descripción completa de las dependencias en la plataforma y como deben ser configuradas de manera segura, incluidas las del sistema operativo, servidor Web y servidor de aplicacion. La configuracion predeterminada del software debe ser segura.<br /> <br /> ===4. ÁREAS CON REQUERIMIENTOS DE SEGURIDAD===<br /> <br /> Los siguientes temas/áreas deben ser considerados durante las actividades de entendimiento de riesgo y definición de requerimientos. Este esfuerzo debe producir un conjunto de requerimientos ajustados, especificos y probables. Ambos, proveedor y cliente deben ser involucrados en este proceso y deben ponerse de acuerdo sobre el conjunto final de requerimientos.<br /> <br /> ;(a) Validación de entradas y condificación : Los requerimientos deben especificar las reglas para canonicalización, validación y codificación de cada dato de entrada a la aplicación, ya sea de usuarios, sistemas de archivos, bases de datos o sistemas externos. La regla predeterminada debe ser que todas las entradas sean validadas a menos que cumplan con una especificacion detallada de que esta permitido. Además, los requerimientos deben especificar las acciones a tomar cuando se reciven entradas no válidas. Especificamente, la aplicación no debe ser susceptible a inyecciones, desbordamientos, manipulación y otros ataques con entradas de usuario corruptas.<br /> <br /> ;(b) Autentificación y manejo de sessiones : Los requerimientos deben especificar como se protegeran las credenciales para autentificación y los identificadores de sesión a través del ciclo de desarrollo de software. Los requerimientos para todas las funciones relacionadas deben ser agregadas incluyendo recuperar contraseñas, cambio de contraseñas, recordar contraseñas, desconexión y conexión multiple.<br /> <br /> ;(c) Control de Acceso : Los requerimientos deben incluir una descripcion detallada de todos los roles (grupos, privilegios, autorizaciones) usadas en la aplicación. Los requerimientos deben indicar todos los activos y funciones que provee la aplicacion. Los requerimientos deben especificar detallada y exactamente los derechos de acceso para cualquier activo y función de cada rol. Se sugiere utilizar un formato de matriz de control de acceso para documentar estas reglas.<br /> <br /> ;(d) Manejo de Errores : Los requerimientos deben detallar como se van a manejar los errores que ocurran dentro del procesamiento. Algunas aplicaciones deberían hacer lo mejor posible en caso de un error, mientras que otras deberían terminar su procesamiento inmediatamente.<br /> <br /> ;(e) Historial : Los requerimientos deben especificar que eventos son relevantes para la seguridad y necesitan ser registrados, como ataques detectados, intentos de conexión fallidos e intentos de exeder la autorización. Los requerimientos deben especificar tambien que information registrar con cada evento, incluyendo hora y fecha, descripción del evento, detalles de aplicación, y otra información útil en esfuerzos forences.<br /> <br /> ;(f) Conexiones a sistemas externos : Los requerimientos deben especifica como la autentificación y cifrado será manejado para todos los systemas externos, tales como bases de datos, directorios y servicios Web. Todas las credenciales requeridas para la comunicación con sistemas externos deben almacenarce cifradas y fuera de el código dentro de archivos de configuración. <br /> <br /> ;(g) Cifrado : Los requerimientos deben especificar que datos deben ser cifrados, como serán cifrados y como todos los certificados y otras credenciales deben ser manejadas. Las aplicaciones deben usar algoritmos estándar implementados en una librerias de cifrado que hayan sido usadas y probadas ampliamente.<br /> <br /> ;(h) Disponibilidad : Los requerimientos deben especificar como protegerse de ataques de negación de servicio. Todos los posibles ataques en la aplicacion deben ser considerados, incluyendo bloqueos de auntentificación, agotamiento de conexiones y otros ataques de agotamiento de recursos.<br /> <br /> ;(i) Configuración segura : Los requerimientos deben especificar que los valores predeterminados para todas las configuraciones relacionadas a seguridad deben ser seguras. Para propósitos de auditoría, el software deberia ser capás de producir un reporte sencillo de leer que muestre los detalles de todas las configuraciones relacionadas con seguridad.<br /> <br /> ;(j) Vulnerabilidades especificas : Los requerimientos deben incluir un conjunto de vulnerabilidades especificas que no deben estar presentes en el software. A menos que sea especificado de otra manera, el software no debe incluir ninguna de las fallas descritas en el la &quot;Lista de OWASP sobre las 10 vulnerabilidades mas críticas en aplicaciones Web&quot;.<br /> <br /> ===5. PERSONAL Y ORGANIZACIÓN===<br /> <br /> ;(a) Arquitecto en seguridad : El desarollador asignará la responsabilidad por la seguridad a un solo recurso técnico experimentado, para ser conocido como el arquitecto de seguridad del proyecto. El arquitecto de seguridad certificará la seguridad de cada entregable.<br /> <br /> ;(b) Entrenamiento en Seguridad : el proveedor será responsable de verificar que todos los miembros del equipo de desarrollo han sido entrenados en tecnicas de programación segura.<br /> <br /> ;(c) Desarrolladores dignos de confianza : El proveedor acuerda realizar las investigaciones de antecendentes apropiadas a todos los miembros del equipo de desarrollo.<br /> <br /> ===6. AMBIENTE DE DESARROLLO===<br /> <br /> ;(a) Codificación segura : El proveedor debe mencionar que herramientas se usarán en el ambiente de desarrollo de software para promover la codificación segura.<br /> <br /> ;(b) Adminstración de configuración : El proveedor debe usar un sistema de control de versiones que autentifique y registre el miembro del equipo asociado con todos los cambios en el código base, todos los archivos de configuración y compilación.<br /> <br /> ;(c) Distribución : El proveedor debe usar un proceso de compilación que construya confiablemente un archivo de distribución completo desde el código fuente. Este proceso debe incluir un método para verificar la integridad de el software entregado al cliente.<br /> <br /> ===7. LIBRERIAS, MARCOS DE DESARROLLO Y PRODUCTOS===<br /> <br /> ;(a) Apertura : El proveedor debe mencionar todas los aplicaciones de terceros usadas en el software, incluyendo todas las librerias, marcos de desarrollo, componentes y otros productos, ya sean comerciales, gratuitos, de código abierto o código cerrado.<br /> <br /> ;(b) Evaluación : El proveedor debe hacer esfuerzos rasonables para asegurar que el sofware de terceros cumple con todos los términos de este contrato y es tan seguro como el código a la medida desarrollado bajo este contrato.<br /> <br /> ===8. REVISIONES DE SEGURIDAD===<br /> <br /> ;(a) Derecho de revisión : El cliente tiene el derecho mandar revisar el software para buscar fallas de seguridad, esto a sus expesas y en cualquier momento dentro de los 60 dias despues de la entrega. El desarrollador acepta proveer apoyo rasonable al equipo de revisión proveyendo el codigo fuente y acceso a los ambientes de pruebas.<br /> <br /> ;(b) Covertura de la revisión : Las revisiones de seguridad deben cubrir todos los aspectos de el software entregado, incluyendo código a la medida, componentes, productos y configuración de sistema.<br /> <br /> ;(c) Alcance de la revisión : Al menos, la revisión debe cubrir todos los requerimientos de seguridad y debería buscar otras vulnerabilidades comunes. La revisión puede incluir una combinación de busqueda automatizada de vulnerabilidades, pruebas de intrusión, análisis estático de código fuente y revisión de código por expertos.<br /> <br /> ;(d) Problemas encontrados : Los problemas de seguridad descubiertos serán reportados a el cliente y proveedor por igual. A todos los problemas se les dará seguimiento y serán reparados como se especifique en la sección de seguimiento de problemas de seguridad de este anexo.<br /> <br /> ===9. ADMINISTRACIÓN DE PROBLEMAS DE SEGURIDAD===<br /> <br /> ;(a) Identificación : El proveedor dara seguimiento a todos los problemas de seguridad descubiertos en todo el ciclo de desarrollo, ya sea un problema en los requerimientos, diseño, implementación, pruebas, publicación u operación. El riesgo asociado con cada problema de seguridad será evaluado, documentado y reportado a el cliente tan pronto como sea posible.<br /> <br /> ;(b) Protección : El proveedor protegerá apropiadamente la información relacionada a problemas de seguridad y la documentación relacionada a ellos, esto, para ayudar a disminuir la probabilidad de las vulnerabilidades en el software operacioneal del cliente sean expuestas.<br /> <br /> ;(c) Reparación : Los problemas de seguridad que sean indentificados antes de la entrega deben ser reparados por el proveedor. Los problemas de seguridad descubiertos despues de la entrega deben ser manejados en la misma manera que otros problemas funcionales según lo especificado en este contrato.<br /> <br /> ===10. CERTEZA===<br /> <br /> ;(a) Certeza : El proveedor proveera un &quot;paquete de certificación&quot; consistente en la documentación de seguridad creada a traves del proceso de desarrollo. El paquete deberá establecer que los requerimientos de seguridad, diseño, implementación y resultados de pruebas fueron completados apropiadamente y todos los problemas de seguridad fueron resueltos apropiadamente.<br /> <br /> ;(b) Auto-Certificación : El aquitecto de seguridad certificará que el software cumple con los requerimientos de seguridad, que todas las actividades de seguridad se realizaron, y que todos los problemas de seguridad identificados han sido documentados y resueltos. Cualquier excepción a el estado de la certificacion debe estar totalmente documentada al momento de la entrega.<br /> <br /> ;(c) No código malicioso : El proveedor garantize que el sofware no debe contener ningun código que no se alinee a algun requerimiento del software y debilite la seguridad de la aplicación, incluyendo viruses, gusanos, bombas de tiempo, puertas traseras, caballos de troya, huevos de pascua y cualquier otra forma de código malicioso.<br /> <br /> ===11. CONCENTIMIENTO Y MANTENIMIENTO DE LA SEGURIDAD===<br /> <br /> ;(a) Consentimiento : El software no debe ser considerado como aceptado hasta que el paquete de certificación este completo y todos los problemas de seguridad han sido resueltos.<br /> <br /> ;(b) Investigación de problemas de seguridad : Despues del concentimiento, si se sospecha (razonablemente) o descubren problemas de seguridad, el proveedor deberá asisitir al cliente en realizar una investigación para determinar la naturaleza del problema. El problema debe ser considerado &quot;nuevo&quot; si no es cubierto por los requerientos de seguridad y esta fuera de el alcance (razonable) de las pruebas de seguridad.<br /> <br /> ;(c) Problemas de seguridad nuevos : El proveedor y el cliente consientes en medir el alcance y esfuerzo requerido para resolver problemas de seguridad nuevos, y negociad de buena fe para alcanzar un acuerdo y realizar el trabajor requerido para solucionarlos.<br /> <br /> ;(d) Otros problemas de seguridad : El proveedor debe usar todos los esfuersos comercialmente rasonables consistentes con practicas de desarrollo comunes en la industria, tomando en cuenta la severidad de el riesgo, para resolver todos los problemas de seguridad considerados nuevos tan pronto como sea posible.<br /> <br /> [[Category:OWASP Legal Project]]<br /> <br /> __NOTOC__</div>

Jorge Correa https://wiki.owasp.org/index.php?title=Anexo_para_Contrato_de_Software_Seguro_de_OWASP&diff=79724 2010-03-12T13:46:05Z

<p>Jorge Correa: </p> <hr /> <div>'''ANEXO DE CONTRATO PARA DESAROLLO DE SOFTWARE SEGURO'''<br /> <br /> ADVERTENCIA: ESTE DOCUMENTO DEBE SER CONSIDERADO COMO UNA GUÍA SOLAMENTE.<br /> OWASP RECOMIENDA VEHEMENTEMENTE QUE CONSULTE UN ABOGADO CALIFICADO<br /> PARA AYUDARLE A NEGOCIAR UN CONTRATO DE SOFTWARE<br /> <br /> == Introducción ==<br /> <br /> Este anexo de contrato pretende ayudar a los proveedores de software y sus clientes a negociar y capturar importantes términos y condiciones contractuales relacionadas a la seguridad en el Software a ser desarrollado o entregado. La razon para este proyecto es que la mayoría de los contratos no mencionan estos temas, y las partes frecuentamente tienen puntos de vista dramaticamente diferentes a lo que en ralidad fue acordado. Creemos que articular claramente estos términos es la mejor manera de asegurarse que ambas partes pueden hacer desiciones informadas sobre como proceder. <br /> <br /> &quot;La seguridad del software comercial mejorará cuando el mercado demande mejor seguridad.<br /> Al menos, cada petición para propuestas de software debería pedir a los vendedores <br /> detallar como van ellos a probar sus productos para encotrar vulnerabilidades de<br /> seguridad. Este paso empezará convenciendo a los vendedores de software empaquetado<br /> y proveedores externos que las compañias valoran la seguridad.&quot;<br /> <br /> -- John Pescatore, Director de investiagacion con Gartner&lt;br&gt; <br /> <br /> Pedimos a los clientes y proveedores que usen este documento como un marco para discutir<br /> espectativas y negociar responsabilidades. Este anexo se creó para ser añadido a un<br /> contrato de desarrollo de software. Estos términos son negociables, significa que ellos<br /> pueden y deben ser discutidos por el cliente y el proveedor.<br /> <br /> == SOBRE EL PROYECTO ==<br /> <br /> Este documento fue creado por la fundación OWASP (Open Web Application Security Project por sus siglas en Inglés), una organización sin animo de lucro con el objetivo de crear herramientas y documentación, gratuita y abierta para asegurar software. Para facilitar su uso en contratación privada, este documento es de dominio publico. Puede encontrar detalles adicionales sobre este proyecto en http://www.owasp.com/index.php/OWASP_Legal_Project. Son Bienvenidos comentarios de ambos, productores y consumidores de software, asi como de la comunidad legal. <br /> <br /> OWASP reconoce gratamente la contribución especial de [http://www.aspectsecurity.com Aspect Security] por su rol en la investigación y preparación de este documento.<br /> <br /> ==OBJECIONES==<br /> <br /> Las siguientes páginas cubren algunas objeciones que escuchamos frecuentemente sobre usar este lenguaje en contratos de desarrollo de software:<br /> <br /> === PERO NO TODOS LOS TÉRMINOS SON CORRECTOS PARA NOSOTROS… ===<br /> <br /> Este documento debe ser considerado un punto de inicio para su contrato. Puede que no le gusten todas las actividades, o puede querer proponer mas. Puede querer asignar responsabilidades de manera diferente. Este documento no pretende capturar exactamente las necesidades de todos los clientes y proveedores de software. Pretende proveer un marco para discutir temas clave, importantes para asegurarse que el software se cree de forma segura. Despues de que tengan una discusión sobre seguridad y alcancen un acuerdo. Puede ajustar el convenio para que concuerde con el contrato.<br /> <br /> === PERO, ¿QUIEN DEBE PAGAR POR ESTAS ACTIVIDADES?… ===<br /> <br /> Este contrato no es sobre poner mas peso al desarollo de software. La pregunta no es sobre si hay costos asociados con seguridad (por supuesto que hay). La pregunta correcta es qué actividades deberían hacerse por ambas partes para minimizar costos, y cuando deberían ocurrir. <br /> <br /> Este anexo no menciona (intensionalmente) sobre el detalle de quién debería pagar por la actividades descritas. Mientras muchas de estas actividades deben estar pasando ya, y son esperadas por muchos clientes, ellas no estan practicadas regularmente en la industria del software. La cuestion de quién paga (y cuándo) debe ser parte de la negociación. <br /> <br /> Calcular el costo de la seguridad es muy difícil. Auque hay costos asociados con realizar actividades de seguridad, hay también costos importantes asociados con ignorar estas actividades. Estamos convencidos el mejor costo-beneficio para desarrollar software es reducir la probabilidad de que fallas de seguridad sean introducidas y minimzar el tiempo entre introducir una falla y arreglarla. <br /> <br /> Una distición importante a hacer cuando calculamos costos es entre construir mecanismos de seguridad y las actividades para asegurarse que esos mecanismos sean correctos y efectivos. Intentar agregar mecanismoa al final de el ciclo de desarrollo puede causar serios problemas de diseño e incrementará el costo dramáticamente. Este convenio promueve decisiones sobre mecanismos para minimizar estos costos. Similarmente, esperar hasta justo antes de la puesta en producción para hacer actividades de aseguramiento, tales como revisión de código y pruebas de intrusión, tambien incrementaría los costos dramaticamente. Creemos que el mejor costo-beneficio para ganar certeza es poner un nivel constante de esfuerzo en el aseguramiento a través del ciclo de desarrollo.<br /> <br /> === PERO EL NIVEL DE RIGOR ESTA INCORRECTO…. ===<br /> <br /> Este convenio asume que el software que esta siendo desarrollado es razonablemente importante para una empresa grande o agencia de gobierno. Hemos seleccionado un &quot;nivel de rigor&quot; para el convenio que es alcanzable por la mayoria de las organizaciones proveedoras de software, e identificaría y manejaría los riesgos más comunes. <br /> <br /> Sin embargo, para el software que va a ser usado en aplicaciones críticas, como aplicaciones médicas, financieras o relacionadas con el ejército. Puede querer incrementar el nivel de rigor. Puede querer agregar revisiones, documentación y actividades adicionales de prueba. Puede querer mejorar el proceso de encontrar, diagnosticar y remediar vulnerabilidades. Para aplicaciones menos sensibles, puede desear reducir o remover actividades.<br /> <br /> === PERO NOSOTROS NO PODEMOS ACEPTAR TANTO RIESGO… ===<br /> <br /> Este convenio pretende facilitar la discusión sobre quién tomaría el riesgo por las vulnerabilidades de seguridad en el software. Por un lado del espectro, el cliente podría tomar todo el riesgo y el proveedor podría entregar código con muchas vulnerabilidades. Por el otro extremo, el proveedor podría tomar todo el riesgo y asumir la responsabilidad de entregar código perfecto. Ambos extremos son irrealizables. <br /> <br /> Actualmente, en este convenio, el proveedor toma el riesgo por problemas que sean descubiertos en los requerimientos o deben ser cubiertos por esfuerzos razonables en pruebas. Pero la remediación de &quot;nuevos&quot; problemas de seguridad tendría que ser pagado por el cliente. Creemos que este es un equilibrio funcional, ya que limita el riesgo adquirido por el proveedor y promueve obtener requerimientos de seguridad por anticipado. Pero hay muchas otras posibles soluciones a este problema. Por favor, dejenos saber si tiene sugerencias alternas, podriamos incluirlas en versiones futuras de este documento. <br /> <br /> Note que la discusión aqui solo cubre el riesgo asociado con arreglar las vulnerabilidades de seguridad en el código, y no incluye los costos asociados con recuperarse de incidentes de seguridad relacionados con explotar cualquiera de esas vulnerabilidades. Estamos interesados en las mejores prácticas en esta area.<br /> <br /> ===PERO COMO PODEMOS ASEGURAR CÓDIGO DE TERCEROS…===<br /> <br /> Casi todos los proyectos de sofware tienen una cantidad importante de código de terceros como librarieas, frameworks y productos. Desde la perspectiva de seguridad, este código es tan importante como el código desarrollado a la medida para su proyecto.<br /> Creemos que la responsabilidad de asegurar la seguridad de este código es llevada mejor por el proveedor, aunque ellos podrían no tener toda la capacidad para garantizar la seguridad por ellos mismos. Sin embargo, La seguridad puede ser parte de el la desición de &quot;construir o comprar&quot;, y esta parece ser la mejor manera de promoverla.<br /> <br /> El proveedor, por supuesto, tiene la opción de pasar la responsabilidad a el proveedor del software de terceros. El desarrolador puede tambien analizar el código de terceros por él mismo o contratar expertos en seguridad para analizarlo por él.<br /> <br /> ===PERO PORQUE DEBO PASAR POR TODO ESTE PROBLEMA…===<br /> <br /> En última instancia, creemos que no hay alternativa para hacer de la seguridad una parte de el proceso de contratación de software. Actualmente, creemos que hay serios malentendidos sobre la seguridad del código que esta siendo desarrollado bajo muchos contratos de desarrollo de software. Esto puede solamente llevar a una cara litigación y a desiciones hechas por individuos con poca experiencia y entendimiento sobre software. Lea el [[Secure software contracting hypothetical case study | Caso de estudio hipotético sobre contratación de software seguro]] para una discusión completa de este problema.<br /> <br /> Hay muchos beneficios al trabajar con este convenio. El principal es que pondrá claras las expectativas entre las partes involucradas. En algunos casos ayudará a evitar demandas cuando problemas de seguridad difíciles aparecen en el software. Tambien, estan son las mismas actividades requeridas por muchas razónes legales y de conformidad con estándares/leyes.<br /> <br /> ===PERO ES MUY DIFÍCIL PRODUCIR TODA ESTA DOCUMENTACIÓN…===<br /> <br /> OWASP no promueve la documentacion por la simpre documentacion. Este convenio esta enfocado en promover la calidad, no la cantidad. Creemos que puede ser posible (en algunos proyectos) cumplir con este contrato con una pequeña evaluacion de riesgo, algunas páginas de requerimientos, un pequeño documento de diseño de seguridad, un plan de pruebas, y algunos resultados de pruebas.<br /> <br /> El objetivo de esta documentación es simplemente asegurar, en cada etapa del desarrollo de software, que se ha puesto la atención apropiada en la seguridad. Un beneficio adiciona es que esta documentacion puede ser recolectada en conjunto para formar un &quot;paquete de certificación&quot; que básicamente esbose el argumento de porque deberiamos confiar que el software hará lo que dice.<br /> <br /> ==ANEXO DE CONTRATO==<br /> <br /> ===1. INTRODUCCIÓN===<br /> <br /> Esta anexo esta hecho para _____________________ (&quot;convenio&quot;) entre el Cliente y el proveedor. Tanto el Cliente como el proveedor acuerdan maximisar la seguridad del software de acuerdo a los siguientes términos.<br /> <br /> <br /> ===2. FILOSOFÍA===<br /> <br /> Esta anexo pretende aclarar los derechos y obligaciones relacionados a seguridad de todas las partes en una relacion de desarrollo de software. Al mayor nivel, las partes acuerdan que:<br /> <br /> ;(a) Las desiciones de seguridad estarán basadas en el riesgo : Las desciciones sobre la seguridad seran tomadas en conunto por el cliente y el proveedor basandose en un firme entendimiento de el riesgo involucrado. <br /> <br /> ;(b) Las actividades de seguridad estarán balanceadas : El esfurzo de seguridad será distribuido equitativamente a través de todo el ciclo de desarollo de software.<br /> <br /> ;(c) Las actividades de seguridad estarán integradas : Todas las actividades y documentación discutidas aqui pueden y deben ser integradas dentro del ciclo de desarrollo de software del proveedor y no mantenerse separadas de el resto del proyecto. Nada en este anexo implica algún processo de desarrollo de software en particular.<br /> <br /> ;(d) Se esperan vulnerabilidades : Todo software contiene defectos, y algunos de estos crearan problemas de seguridad. Ambos, cliente y proveedor se esforzará para identificar las vulnerabilidades tan pronto como sea posible en el ciclo de desarrollo.<br /> <br /> ;(e) La información sobre seguridad será comunicada por completo : Toda la información relevante para la seguridad se compartirá entre el cliente y el proveedor inmediatamente y completamente.<br /> <br /> ;(f) Se requerirá solo documentacion de seguridad necesaria : La documentación de seguridad no necesita ser demasiado amplia para describir claramente el diseño de seguridad, análisis de riesgo y problemas.<br /> <br /> ===3. ACTIVIDADES EN EL CICLO DE DESARROLLO===<br /> <br /> ;(a) Entendimiento del Riesgo : El proveedor y el cliente acuerdan trabajar juntos para entender y documentar los riesgos que enfrenta la aplicacion. Este esfuerzo debe identificar los riesgos clave para los activos y funciones importantes que provee la aplicación. Cada uno de los temas listados en la sección de requerimientos debe ser considerado.<br /> <br /> ;(b) Requerimientos : Basado en los riesgos, El proveedor y cliente acuerda trabajar juntos para crear requerimientos de seguridad detallados como parte de la especificacion de el software a ser desarrollado. Cada uno de los temas listados en la sección de requerimientos de este anexo deben ser discutidos y evaluados por ambos, cliente y proveedor. Estos requerimientos pueden ser satisfechos por software creado a la medida, software de terceros, o la plataforma. <br /> <br /> ;(c) Diseño : el desarollador acuerda proveer documentation que explique claramente el diseño para adquirir cada uno de los requerimientos de seguridad. En muchos de los casos, esta documentacion describirá los mecanismos de seguridad, donde se incluiran dentro de la arquitectura, y todos los patrones de diseño relevantes para asegurar su uso adecuado. El diseño debe especificar claramente si tales mecanismos vienen de software a la medida, software de terceros o de la plataforma.<br /> <br /> ;(d) Implementación : El proveedor acuerda entregar y seguir un conjunto de lineamientos de codificación segura. Estos lineamientos indicarán como sele de debe dar formato, estructurar y comentar el código fuente. Todo código relacionado a seguridad debe ser comentado profundamente. Guías sobre como evitar vulnerabilidades se seguridad comunes debe ser incluida. Tambien, todo el código debe ser revisado por al menos otro desarollador basandose en los requerimientos de seguridad y los lineamientos de codificación antes de ser conciderado listo para pruebas unitarias.<br /> <br /> ;(e) Pruebas y análisis de seguridad : El proveedor acuerda entregar y seguir un plan de pruebas de seguridad que defina como se realizarán las pruebas o bien establecer como cada uno de los requerimientos de seguridad va a ser complido. El nivel de rigor de esta actividad debe ser considerado y detallado en un plan. El proveedor ejecutará el plan de prueba y proveera los resultados a el cliente.<br /> <br /> ;(f) Publicación segura : El proveedor acuerda entregar lineamientos de configuración segura que describan completamente todas las opciones de configuracion relacionadas con seguridad y sus implicaciones para la seguridad del software en su conjunto. Los lineamientos deben incluir una descripción completa de las dependencias en la plataforma y como deben ser configuradas de manera segura, incluidas las del sistema operativo, servidor Web y servidor de aplicacion. La configuracion predeterminada del software debe ser segura.<br /> <br /> ===4. ÁREAS CON REQUERIMIENTOS DE SEGURIDAD===<br /> <br /> Los siguientes temas/áreas deben ser considerados durante las actividades de entendimiento de riesgo y definición de requerimientos. Este esfuerzo debe producir un conjunto de requerimientos ajustados, especificos y probables. Ambos, proveedor y cliente deben ser involucrados en este proceso y deben ponerse de acuerdo sobre el conjunto final de requerimientos.<br /> <br /> ;(a) Validación de entradas y condificación : Los requerimientos deben especificar las reglas para canonicalización, validación y codificación de cada dato de entrada a la aplicación, ya sea de usuarios, sistemas de archivos, bases de datos o sistemas externos. La regla predeterminada debe ser que todas las entradas sean validadas a menos que cumplan con una especificacion detallada de que esta permitido. Además, los requerimientos deben especificar las acciones a tomar cuando se reciven entradas no válidas. Especificamente, la aplicación no debe ser susceptible a inyecciones, desbordamientos, manipulación y otros ataques con entradas de usuario corruptas.<br /> <br /> ;(b) Autentificación y manejo de sessiones : Los requerimientos deben especificar como se protegeran las credenciales para autentificación y los identificadores de sesión a través del ciclo de desarrollo de software. Los requerimientos para todas las funciones relacionadas deben ser agregadas incluyendo recuperar contraseñas, cambio de contraseñas, recordar contraseñas, desconexión y conexión multiple.<br /> <br /> ;(c) Control de Acceso : Los requerimientos deben incluir una descripcion detallada de todos los roles (grupos, privilegios, autorizaciones) usadas en la aplicación. Los requerimientos deben indicar todos los activos y funciones que provee la aplicacion. Los requerimientos deben especificar detallada y exactamente los derechos de acceso para cualquier activo y función de cada rol. Se sugiere utilizar un formato de matriz de control de acceso para documentar estas reglas.<br /> <br /> ;(d) Manejo de Errores : Los requerimientos deben detallar como se van a manejar los errores que ocurran dentro del procesamiento. Algunas aplicaciones deberían hacer lo mejor posible en caso de un error, mientras que otras deberían terminar su procesamiento inmediatamente.<br /> <br /> ;(e) Historial : Los requerimientos deben especificar que eventos son relevantes para la seguridad y necesitan ser registrados, como ataques detectados, intentos de conexión fallidos e intentos de exeder la autorización. Los requerimientos deben especificar tambien que information registrar con cada evento, incluyendo hora y fecha, descripción del evento, detalles de aplicación, y otra información útil en esfuerzos forences.<br /> <br /> ;(f) Conexiones a sistemas externos : Los requerimientos deben especifica como la autentificación y cifrado será manejado para todos los systemas externos, tales como bases de datos, directorios y servicios Web. Todas las credenciales requeridas para la comunicación con sistemas externos deben almacenarce cifradas y fuera de el código dentro de archivos de configuración. <br /> <br /> ;(g) Cifrado : Los requerimientos deben especificar que datos deben ser cifrados, como serán cifrados y como todos los certificados y otras credenciales deben ser manejadas. Las aplicaciones deben usar algoritmos estándar implementados en una librerias de cifrado que hayan sido usadas y probadas ampliamente.<br /> <br /> ;(h) Disponibilidad : Los requerimientos deben especificar como protegerse de ataques de negación de servicio. Todos los posibles ataques en la aplicacion deben ser considerados, incluyendo bloqueos de auntentificación, agotamiento de conexiones y otros ataques de agotamiento de recursos.<br /> <br /> ;(i) Configuración segura : Los requerimientos deben especificar que los valores predeterminados para todas las configuraciones relacionadas a seguridad deben ser seguras. Para propósitos de auditoría, el software deberia ser capás de producir un reporte sencillo de leer que muestre los detalles de todas las configuraciones relacionadas con seguridad.<br /> <br /> ;(j) Vulnerabilidades especificas : Los requerimientos deben incluir un conjunto de vulnerabilidades especificas que no deben estar presentes en el software. A menos que sea especificado de otra manera, el software no debe incluir ninguna de las fallas descritas en el la &quot;Lista de OWASP sobre las 10 vulnerabilidades mas críticas en aplicaciones Web&quot;.<br /> <br /> ===5. PERSONAL Y ORGANIZACIÓN===<br /> <br /> ;(a) Arquitecto en seguridad : El desarollador asignará la responsabilidad por la seguridad a un solo recurso técnico experimentado, para ser conocido como el arquitecto de seguridad del proyecto. El arquitecto de seguridad certificará la seguridad de cada entregable.<br /> <br /> ;(b) Entrenamiento en Seguridad : el proveedor será responsable de verificar que todos los miembros del equipo de desarrollo han sido entrenados en tecnicas de programación segura.<br /> <br /> ;(c) Desarrolladores dignos de confianza : El proveedor acuerda realizar las investigaciones de antecendentes apropiadas a todos los miembros del equipo de desarrollo.<br /> <br /> ===6. AMBIENTE DE DESARROLLO===<br /> <br /> ;(a) Codificación segura : El proveedor debe mencionar que herramientas se usarán en el ambiente de desarrollo de software para promover la codificación segura.<br /> <br /> ;(b) Adminstración de configuración : El proveedor debe usar un sistema de control de versiones que autentifique y registre el miembro del equipo asociado con todos los cambios en el código base, todos los archivos de configuración y compilación.<br /> <br /> ;(c) Distribución : El proveedor debe usar un proceso de compilación que construya confiablemente un archivo de distribución completo desde el código fuente. Este proceso debe incluir un método para verificar la integridad de el software entregado al cliente.<br /> <br /> ===7. LIBRERIAS, MARCOS DE DESARROLLO Y PRODUCTOS===<br /> <br /> ;(a) Apertura : El proveedor debe mencionar todas los aplicaciones de terceros usadas en el software, incluyendo todas las librerias, marcos de desarrollo, componentes y otros productos, ya sean comerciales, gratuitos, de código abierto o código cerrado.<br /> <br /> ;(b) Evaluación : El proveedor debe hacer esfuerzos rasonables para asegurar que el sofware de terceros cumple con todos los términos de este contrato y es tan seguro como el código a la medida desarrollado bajo este contrato.<br /> <br /> ===8. REVISIONES DE SEGURIDAD===<br /> <br /> ;(a) Derecho de revisión : El cliente tiene el derecho mandar revisar el software para buscar fallas de seguridad, esto a sus expesas y en cualquier momento dentro de los 60 dias despues de la entrega. El desarrollador acepta proveer apoyo rasonable al equipo de revisión proveyendo el codigo fuente y acceso a los ambientes de pruebas.<br /> <br /> ;(b) Covertura de la revisión : Las revisiones de seguridad deben cubrir todos los aspectos de el software entregado, incluyendo código a la medida, componentes, productos y configuración de sistema.<br /> <br /> ;(c) Alcance de la revisión : Al menos, la revisión debe cubrir todos los requerimientos de seguridad y debería buscar otras vulnerabilidades comunes. La revisión puede incluir una combinación de busqueda automatizada de vulnerabilidades, pruebas de intrusión, análisis estático de código fuente y revisión de código por expertos.<br /> <br /> ;(d) Problemas encontrados : Los problemas de seguridad descubiertos serán reportados a el cliente y proveedor por igual. A todos los problemas se les dará seguimiento y serán reparados como se especifique en la sección de seguimiento de problemas de seguridad de este anexo.<br /> <br /> ===9. ADMINISTRACIÓN DE PROBLEMAS DE SEGURIDAD===<br /> <br /> ;(a) Identificación : El proveedor dara seguimiento a todos los problemas de seguridad descubiertos en todo el ciclo de desarrollo, ya sea un problema en los requerimientos, diseño, implementación, pruebas, publicación u operación. El riesgo asociado con cada problema de seguridad será evaluado, documentado y reportado a el cliente tan pronto como sea posible.<br /> <br /> ;(b) Protección : El proveedor protegerá apropiadamente la información relacionada a problemas de seguridad y la documentación relacionada a ellos, esto, para ayudar a disminuir la probabilidad de las vulnerabilidades en el software operacioneal del cliente sean expuestas.<br /> <br /> ;(c) Reparación : Los problemas de seguridad que sean indentificados antes de la entrega deben ser reparados por el proveedor. Los problemas de seguridad descubiertos despues de la entrega deben ser manejados en la misma manera que otros problemas funcionales según lo especificado en este contrato.<br /> <br /> ===10. CERTEZA===<br /> <br /> ;(a) Certeza : El proveedor proveera un &quot;paquete de certificación&quot; consistente en la documentación de seguridad creada a traves del proceso de desarrollo. El paquete deberá establecer que los requerimientos de seguridad, diseño, implementación y resultados de pruebas fueron completados apropiadamente y todos los problemas de seguridad fueron resueltos apropiadamente.<br /> <br /> ;(b) Auto-Certificación : El aquitecto de seguridad certificará que el software cumple con los requerimientos de seguridad, que todas las actividades de seguridad se realizaron, y que todos los problemas de seguridad identificados han sido documentados y resueltos. Cualquier excepción a el estado de la certificacion debe estar totalmente documentada al momento de la entrega.<br /> <br /> ;(c) No código malicioso : El proveedor garantize que el sofware no debe contener ningun código que no se alinee a algun requerimiento del software y debilite la seguridad de la aplicación, incluyendo viruses, gusanos, bombas de tiempo, puertas traseras, caballos de troya, huevos de pascua y cualquier otra forma de código malicioso.<br /> <br /> ===11. CONCENTIMIENTO Y MANTENIMIENTO DE LA SEGURIDAD===<br /> <br /> ;(a) Consentimiento : El software no debe ser considerado como aceptado hasta que el paquete de certificación este completo y todos los problemas de seguridad han sido resueltos.<br /> <br /> ;(b) Investigación de problemas de seguridad : Despues del concentimiento, si se sospecha (razonablemente) o descubren problemas de seguridad, el proveedor deberá asisitir al cliente en realizar una investigación para determinar la naturaleza del problema. El problema debe ser considerado &quot;nuevo&quot; si no es cubierto por los requerientos de seguridad y esta fuera de el alcance (razonable) de las pruebas de seguridad.<br /> <br /> ;(c) Problemas de seguridad nuevos : El proveedor y el cliente consientes en medir el alcance y esfuerzo requerido para resolver problemas de seguridad nuevos, y negociad de buena fe para alcanzar un acuerdo y realizar el trabajor requerido para solucionarlos.<br /> <br /> ;(d) Otros problemas de seguridad : El proveedor debe usar todos los esfuersos comercialmente rasonables consistentes con practicas de desarrollo comunes en la industria, tomando en cuenta la severidad de el riesgo, para resolver todos los problemas de seguridad considerados nuevos tan pronto como sea posible.<br /> <br /> [[Category:OWASP Legal Project]]<br /> <br /> __NOTOC__</div>

Jorge Correa https://wiki.owasp.org/index.php?title=Anexo_para_Contrato_de_Software_Seguro_de_OWASP&diff=79723 2010-03-12T13:44:28Z

<p>Jorge Correa: </p> <hr /> <div>'''ANEXO DE CONTRATO PARA DESAROLLO DE SOFTWARE SEGURO'''<br /> <br /> ADVERTENCIA: ESTE DOCUMENTO DEBE SER CONSIDERADO COMO UNA GUÍA SOLAMENTE.<br /> OWASP RECOMIENDA VEHEMENTEMENTE QUE CONSULTE UN ABOGADO CALIFICADO<br /> PARA AYUDARLE A NEGOCIAR UN CONTRATO DE SOFTWARE<br /> <br /> == Introducción ==<br /> <br /> Este anexo de contrato pretende ayudar a los proveedores de software y sus clientes a negociar y capturar importantes términos y condiciones contractuales relacionadas a la seguridad en el Software a ser desarrollado o entregado. La razon para este proyecto es que la mayoría de los contratos no mencionan estos temas, y las partes frecuentamente tienen puntos de vista dramaticamente diferentes a lo que en ralidad fue acordado. Creemos que articular claramente estos términos es la mejor manera de asegurarse que ambas partes pueden hacer desiciones informadas sobre como proceder. <br /> <br /> &quot;La seguridad del software comercial mejorará cuando el mercado demande mejor seguridad.<br /> Al menos, cada petición para propuestas de software debería pedir a los vendedores <br /> detallar como van ellos a probar sus productos para encotrar vulnerabilidades de<br /> seguridad. Este paso empezará convenciendo a los vendedores de software empaquetado<br /> y proveedores externos que las compañias valoran la seguridad.&quot;<br /> <br /> -- John Pescatore, Director de investiagacion con Gartner&lt;br&gt; <br /> <br /> Pedimos a los clientes y proveedores que usen este documento como un marco para discutir<br /> espectativas y negociar responsabilidades. Este anexo se creó para ser añadido a un<br /> contrato de desarrollo de software. Estos términos son negociables, significa que ellos<br /> pueden y deben ser discutidos por el cliente y el proveedor.<br /> <br /> == SOBRE EL PROYECTO ==<br /> <br /> Este documento fue creado por la fundación OWASP (Open Web Application Security Project por sus siglas en Inglés), una organización sin animo de lucro con el objetivo de crear herramientas y documentación, gratuita y abierta para asegurar software. Para facilitar su uso en contratación privada, este documento es de dominio publico. Puede encontrar detalles adicionales sobre este proyecto en http://www.owasp.com/index.php/OWASP_Legal_Project. Son Bienvenidos comentarios de ambos, productores y consumidores de software, asi como de la comunidad legal. <br /> <br /> OWASP reconoce gratamente la contribución especial de [http://www.aspectsecurity.com Aspect Security] por su rol en la investigación y preparación de este documento.<br /> <br /> ==OBJECIONES==<br /> <br /> Las siguientes páginas cubren algunas objeciones que escuchamos frecuentemente sobre usar este lenguaje en contratos de desarrollo de software:<br /> <br /> === PERO NO TODOS LOS TÉRMINOS SON CORRECTOS PARA NOSOTROS… ===<br /> <br /> Este documento debe ser considerado un punto de inicio para su contrato. Puede que no le gusten todas las actividades, o puede querer proponer mas. Puede querer asignar responsabilidades de manera diferente. Este documento no pretende capturar exactamente las necesidades de todos los clientes y proveedores de software. Pretende proveer un marco para discutir temas clave, importantes para asegurarse que el software se cree de forma segura. Despues de que tengan una discusión sobre seguridad y alcancen un acuerdo. Puede ajustar el convenio para que concuerde con el contrato.<br /> <br /> === PERO, ¿QUIEN DEBE PAGAR POR ESTAS ACTIVIDADES?… ===<br /> <br /> Este contrato no es sobre poner mas peso al desarollo de software. La pregunta no es sobre si hay costos asociados con seguridad (por supuesto que hay). La pregunta correcta es qué actividades deberían hacerse por ambas partes para minimizar costos, y cuando deberían ocurrir. <br /> <br /> Este anexo no menciona (intensionalmente) sobre el detalle de quién debería pagar por la actividades descritas. Mientras muchas de estas actividades deben estar pasando ya, y son esperadas por muchos clientes, ellas no estan practicadas regularmente en la industria del software. La cuestion de quién paga (y cuándo) debe ser parte de la negociación. <br /> <br /> Calcular el costo de la seguridad es muy difícil. Auque hay costos asociados con realizar actividades de seguridad, hay también costos importantes asociados con ignorar estas actividades. Estamos convencidos el mejor costo-beneficio para desarrollar software es reducir la probabilidad de que fallas de seguridad sean introducidas y minimzar el tiempo entre introducir una falla y arreglarla. <br /> <br /> Una distición importante a hacer cuando calculamos costos es entre construir mecanismos de seguridad y las actividades para asegurarse que esos mecanismos sean correctos y efectivos. Intentar agregar mecanismoa al final de el ciclo de desarrollo puede causar serios problemas de diseño e incrementará el costo dramáticamente. Este convenio promueve decisiones sobre mecanismos para minimizar estos costos. Similarmente, esperar hasta justo antes de la puesta en producción para hacer actividades de aseguramiento, tales como revisión de código y pruebas de intrusión, tambien incrementaría los costos dramaticamente. Creemos que el mejor costo-beneficio para ganar certeza es poner un nivel constante de esfuerzo en el aseguramiento a través del ciclo de desarrollo.<br /> <br /> === PERO EL NIVEL DE RIGOR ESTA INCORRECTO…. ===<br /> <br /> Este convenio asume que el software que esta siendo desarrollado es razonablemente importante para una empresa grande o agencia de gobierno. Hemos seleccionado un &quot;nivel de rigor&quot; para el convenio que es alcanzable por la mayoria de las organizaciones proveedoras de software, e identificaría y manejaría los riesgos más comunes. <br /> <br /> Sin embargo, para el software que va a ser usado en aplicaciones críticas, como aplicaciones médicas, financieras o relacionadas con el ejército. Puede querer incrementar el nivel de rigor. Puede querer agregar revisiones, documentación y actividades adicionales de prueba. Puede querer mejorar el proceso de encontrar, diagnosticar y remediar vulnerabilidades. Para aplicaciones menos sensibles, puede desear reducir o remover actividades.<br /> <br /> ===PERO NOSOTROS NO PODEMOS ACEPTAR TANTO RIESGO…===<br /> Este convenio pretende facilitar la discusión sobre quien tomaría el riesgo por las vulnerabilidades de seguridad en el software. Por un lado del espectro, el cliente podria tomar todo el riesgo y el proveedor podria entregar código con muchas vulnerabilidades. Por el otro extremo, el proveedor podría tomar todo el riesgo y asumir la responsabilidad de entregar código perfecto. Ambos extremos son irrealizables.<br /> <br /> Actualmente, en este convenio, el proveedor toma el riesgo por problemas que sean descubiertos en los requerimientos o deben ser cubiertos por esfuerzos razonables en pruebas. Pero la remediación de &quot;nuevos&quot; problemas de seguridad tendría que ser pagado por el cliente. Creemos que este es un equilibrio funcional, ya que limita el riesgo adquirido por el proveedor y promueve obtener requerimientos de seguridad por anticipado. Pero hay muchas otras posibles soluciones a este problema. Por favor, dejenos saber si tiene sugerencias alternas, podriamos incluirlas en versiones futuras de este documento.<br /> <br /> Note que la discusión aqui solo cubre el riesgo asociado con arreglar las vulnerabilidades de seguridad en el código, y no incluye los costos asociados con recuperarse de incidentes de seguridad relacionados con explotar cualquiera de esas vulnerabilidades. Estamos interesados en mejores prácticas en esta area.<br /> <br /> ===PERO COMO PODEMOS ASEGURAR CÓDIGO DE TERCEROS…===<br /> <br /> Casi todos los proyectos de sofware tienen una cantidad importante de código de terceros como librarieas, frameworks y productos. Desde la perspectiva de seguridad, este código es tan importante como el código desarrollado a la medida para su proyecto.<br /> Creemos que la responsabilidad de asegurar la seguridad de este código es llevada mejor por el proveedor, aunque ellos podrían no tener toda la capacidad para garantizar la seguridad por ellos mismos. Sin embargo, La seguridad puede ser parte de el la desición de &quot;construir o comprar&quot;, y esta parece ser la mejor manera de promoverla.<br /> <br /> El proveedor, por supuesto, tiene la opción de pasar la responsabilidad a el proveedor del software de terceros. El desarrolador puede tambien analizar el código de terceros por él mismo o contratar expertos en seguridad para analizarlo por él.<br /> <br /> ===PERO PORQUE DEBO PASAR POR TODO ESTE PROBLEMA…===<br /> <br /> En última instancia, creemos que no hay alternativa para hacer de la seguridad una parte de el proceso de contratación de software. Actualmente, creemos que hay serios malentendidos sobre la seguridad del código que esta siendo desarrollado bajo muchos contratos de desarrollo de software. Esto puede solamente llevar a una cara litigación y a desiciones hechas por individuos con poca experiencia y entendimiento sobre software. Lea el [[Secure software contracting hypothetical case study | Caso de estudio hipotético sobre contratación de software seguro]] para una discusión completa de este problema.<br /> <br /> Hay muchos beneficios al trabajar con este convenio. El principal es que pondrá claras las expectativas entre las partes involucradas. En algunos casos ayudará a evitar demandas cuando problemas de seguridad difíciles aparecen en el software. Tambien, estan son las mismas actividades requeridas por muchas razónes legales y de conformidad con estándares/leyes.<br /> <br /> ===PERO ES MUY DIFÍCIL PRODUCIR TODA ESTA DOCUMENTACIÓN…===<br /> <br /> OWASP no promueve la documentacion por la simpre documentacion. Este convenio esta enfocado en promover la calidad, no la cantidad. Creemos que puede ser posible (en algunos proyectos) cumplir con este contrato con una pequeña evaluacion de riesgo, algunas páginas de requerimientos, un pequeño documento de diseño de seguridad, un plan de pruebas, y algunos resultados de pruebas.<br /> <br /> El objetivo de esta documentación es simplemente asegurar, en cada etapa del desarrollo de software, que se ha puesto la atención apropiada en la seguridad. Un beneficio adiciona es que esta documentacion puede ser recolectada en conjunto para formar un &quot;paquete de certificación&quot; que básicamente esbose el argumento de porque deberiamos confiar que el software hará lo que dice.<br /> <br /> ==ANEXO DE CONTRATO==<br /> <br /> ===1. INTRODUCCIÓN===<br /> <br /> Esta anexo esta hecho para _____________________ (&quot;convenio&quot;) entre el Cliente y el proveedor. Tanto el Cliente como el proveedor acuerdan maximisar la seguridad del software de acuerdo a los siguientes términos.<br /> <br /> <br /> ===2. FILOSOFÍA===<br /> <br /> Esta anexo pretende aclarar los derechos y obligaciones relacionados a seguridad de todas las partes en una relacion de desarrollo de software. Al mayor nivel, las partes acuerdan que:<br /> <br /> ;(a) Las desiciones de seguridad estarán basadas en el riesgo : Las desciciones sobre la seguridad seran tomadas en conunto por el cliente y el proveedor basandose en un firme entendimiento de el riesgo involucrado. <br /> <br /> ;(b) Las actividades de seguridad estarán balanceadas : El esfurzo de seguridad será distribuido equitativamente a través de todo el ciclo de desarollo de software.<br /> <br /> ;(c) Las actividades de seguridad estarán integradas : Todas las actividades y documentación discutidas aqui pueden y deben ser integradas dentro del ciclo de desarrollo de software del proveedor y no mantenerse separadas de el resto del proyecto. Nada en este anexo implica algún processo de desarrollo de software en particular.<br /> <br /> ;(d) Se esperan vulnerabilidades : Todo software contiene defectos, y algunos de estos crearan problemas de seguridad. Ambos, cliente y proveedor se esforzará para identificar las vulnerabilidades tan pronto como sea posible en el ciclo de desarrollo.<br /> <br /> ;(e) La información sobre seguridad será comunicada por completo : Toda la información relevante para la seguridad se compartirá entre el cliente y el proveedor inmediatamente y completamente.<br /> <br /> ;(f) Se requerirá solo documentacion de seguridad necesaria : La documentación de seguridad no necesita ser demasiado amplia para describir claramente el diseño de seguridad, análisis de riesgo y problemas.<br /> <br /> ===3. ACTIVIDADES EN EL CICLO DE DESARROLLO===<br /> <br /> ;(a) Entendimiento del Riesgo : El proveedor y el cliente acuerdan trabajar juntos para entender y documentar los riesgos que enfrenta la aplicacion. Este esfuerzo debe identificar los riesgos clave para los activos y funciones importantes que provee la aplicación. Cada uno de los temas listados en la sección de requerimientos debe ser considerado.<br /> <br /> ;(b) Requerimientos : Basado en los riesgos, El proveedor y cliente acuerda trabajar juntos para crear requerimientos de seguridad detallados como parte de la especificacion de el software a ser desarrollado. Cada uno de los temas listados en la sección de requerimientos de este anexo deben ser discutidos y evaluados por ambos, cliente y proveedor. Estos requerimientos pueden ser satisfechos por software creado a la medida, software de terceros, o la plataforma. <br /> <br /> ;(c) Diseño : el desarollador acuerda proveer documentation que explique claramente el diseño para adquirir cada uno de los requerimientos de seguridad. En muchos de los casos, esta documentacion describirá los mecanismos de seguridad, donde se incluiran dentro de la arquitectura, y todos los patrones de diseño relevantes para asegurar su uso adecuado. El diseño debe especificar claramente si tales mecanismos vienen de software a la medida, software de terceros o de la plataforma.<br /> <br /> ;(d) Implementación : El proveedor acuerda entregar y seguir un conjunto de lineamientos de codificación segura. Estos lineamientos indicarán como sele de debe dar formato, estructurar y comentar el código fuente. Todo código relacionado a seguridad debe ser comentado profundamente. Guías sobre como evitar vulnerabilidades se seguridad comunes debe ser incluida. Tambien, todo el código debe ser revisado por al menos otro desarollador basandose en los requerimientos de seguridad y los lineamientos de codificación antes de ser conciderado listo para pruebas unitarias.<br /> <br /> ;(e) Pruebas y análisis de seguridad : El proveedor acuerda entregar y seguir un plan de pruebas de seguridad que defina como se realizarán las pruebas o bien establecer como cada uno de los requerimientos de seguridad va a ser complido. El nivel de rigor de esta actividad debe ser considerado y detallado en un plan. El proveedor ejecutará el plan de prueba y proveera los resultados a el cliente.<br /> <br /> ;(f) Publicación segura : El proveedor acuerda entregar lineamientos de configuración segura que describan completamente todas las opciones de configuracion relacionadas con seguridad y sus implicaciones para la seguridad del software en su conjunto. Los lineamientos deben incluir una descripción completa de las dependencias en la plataforma y como deben ser configuradas de manera segura, incluidas las del sistema operativo, servidor Web y servidor de aplicacion. La configuracion predeterminada del software debe ser segura.<br /> <br /> ===4. ÁREAS CON REQUERIMIENTOS DE SEGURIDAD===<br /> <br /> Los siguientes temas/áreas deben ser considerados durante las actividades de entendimiento de riesgo y definición de requerimientos. Este esfuerzo debe producir un conjunto de requerimientos ajustados, especificos y probables. Ambos, proveedor y cliente deben ser involucrados en este proceso y deben ponerse de acuerdo sobre el conjunto final de requerimientos.<br /> <br /> ;(a) Validación de entradas y condificación : Los requerimientos deben especificar las reglas para canonicalización, validación y codificación de cada dato de entrada a la aplicación, ya sea de usuarios, sistemas de archivos, bases de datos o sistemas externos. La regla predeterminada debe ser que todas las entradas sean validadas a menos que cumplan con una especificacion detallada de que esta permitido. Además, los requerimientos deben especificar las acciones a tomar cuando se reciven entradas no válidas. Especificamente, la aplicación no debe ser susceptible a inyecciones, desbordamientos, manipulación y otros ataques con entradas de usuario corruptas.<br /> <br /> ;(b) Autentificación y manejo de sessiones : Los requerimientos deben especificar como se protegeran las credenciales para autentificación y los identificadores de sesión a través del ciclo de desarrollo de software. Los requerimientos para todas las funciones relacionadas deben ser agregadas incluyendo recuperar contraseñas, cambio de contraseñas, recordar contraseñas, desconexión y conexión multiple.<br /> <br /> ;(c) Control de Acceso : Los requerimientos deben incluir una descripcion detallada de todos los roles (grupos, privilegios, autorizaciones) usadas en la aplicación. Los requerimientos deben indicar todos los activos y funciones que provee la aplicacion. Los requerimientos deben especificar detallada y exactamente los derechos de acceso para cualquier activo y función de cada rol. Se sugiere utilizar un formato de matriz de control de acceso para documentar estas reglas.<br /> <br /> ;(d) Manejo de Errores : Los requerimientos deben detallar como se van a manejar los errores que ocurran dentro del procesamiento. Algunas aplicaciones deberían hacer lo mejor posible en caso de un error, mientras que otras deberían terminar su procesamiento inmediatamente.<br /> <br /> ;(e) Historial : Los requerimientos deben especificar que eventos son relevantes para la seguridad y necesitan ser registrados, como ataques detectados, intentos de conexión fallidos e intentos de exeder la autorización. Los requerimientos deben especificar tambien que information registrar con cada evento, incluyendo hora y fecha, descripción del evento, detalles de aplicación, y otra información útil en esfuerzos forences.<br /> <br /> ;(f) Conexiones a sistemas externos : Los requerimientos deben especifica como la autentificación y cifrado será manejado para todos los systemas externos, tales como bases de datos, directorios y servicios Web. Todas las credenciales requeridas para la comunicación con sistemas externos deben almacenarce cifradas y fuera de el código dentro de archivos de configuración. <br /> <br /> ;(g) Cifrado : Los requerimientos deben especificar que datos deben ser cifrados, como serán cifrados y como todos los certificados y otras credenciales deben ser manejadas. Las aplicaciones deben usar algoritmos estándar implementados en una librerias de cifrado que hayan sido usadas y probadas ampliamente.<br /> <br /> ;(h) Disponibilidad : Los requerimientos deben especificar como protegerse de ataques de negación de servicio. Todos los posibles ataques en la aplicacion deben ser considerados, incluyendo bloqueos de auntentificación, agotamiento de conexiones y otros ataques de agotamiento de recursos.<br /> <br /> ;(i) Configuración segura : Los requerimientos deben especificar que los valores predeterminados para todas las configuraciones relacionadas a seguridad deben ser seguras. Para propósitos de auditoría, el software deberia ser capás de producir un reporte sencillo de leer que muestre los detalles de todas las configuraciones relacionadas con seguridad.<br /> <br /> ;(j) Vulnerabilidades especificas : Los requerimientos deben incluir un conjunto de vulnerabilidades especificas que no deben estar presentes en el software. A menos que sea especificado de otra manera, el software no debe incluir ninguna de las fallas descritas en el la &quot;Lista de OWASP sobre las 10 vulnerabilidades mas críticas en aplicaciones Web&quot;.<br /> <br /> ===5. PERSONAL Y ORGANIZACIÓN===<br /> <br /> ;(a) Arquitecto en seguridad : El desarollador asignará la responsabilidad por la seguridad a un solo recurso técnico experimentado, para ser conocido como el arquitecto de seguridad del proyecto. El arquitecto de seguridad certificará la seguridad de cada entregable.<br /> <br /> ;(b) Entrenamiento en Seguridad : el proveedor será responsable de verificar que todos los miembros del equipo de desarrollo han sido entrenados en tecnicas de programación segura.<br /> <br /> ;(c) Desarrolladores dignos de confianza : El proveedor acuerda realizar las investigaciones de antecendentes apropiadas a todos los miembros del equipo de desarrollo.<br /> <br /> ===6. AMBIENTE DE DESARROLLO===<br /> <br /> ;(a) Codificación segura : El proveedor debe mencionar que herramientas se usarán en el ambiente de desarrollo de software para promover la codificación segura.<br /> <br /> ;(b) Adminstración de configuración : El proveedor debe usar un sistema de control de versiones que autentifique y registre el miembro del equipo asociado con todos los cambios en el código base, todos los archivos de configuración y compilación.<br /> <br /> ;(c) Distribución : El proveedor debe usar un proceso de compilación que construya confiablemente un archivo de distribución completo desde el código fuente. Este proceso debe incluir un método para verificar la integridad de el software entregado al cliente.<br /> <br /> ===7. LIBRERIAS, MARCOS DE DESARROLLO Y PRODUCTOS===<br /> <br /> ;(a) Apertura : El proveedor debe mencionar todas los aplicaciones de terceros usadas en el software, incluyendo todas las librerias, marcos de desarrollo, componentes y otros productos, ya sean comerciales, gratuitos, de código abierto o código cerrado.<br /> <br /> ;(b) Evaluación : El proveedor debe hacer esfuerzos rasonables para asegurar que el sofware de terceros cumple con todos los términos de este contrato y es tan seguro como el código a la medida desarrollado bajo este contrato.<br /> <br /> ===8. REVISIONES DE SEGURIDAD===<br /> <br /> ;(a) Derecho de revisión : El cliente tiene el derecho mandar revisar el software para buscar fallas de seguridad, esto a sus expesas y en cualquier momento dentro de los 60 dias despues de la entrega. El desarrollador acepta proveer apoyo rasonable al equipo de revisión proveyendo el codigo fuente y acceso a los ambientes de pruebas.<br /> <br /> ;(b) Covertura de la revisión : Las revisiones de seguridad deben cubrir todos los aspectos de el software entregado, incluyendo código a la medida, componentes, productos y configuración de sistema.<br /> <br /> ;(c) Alcance de la revisión : Al menos, la revisión debe cubrir todos los requerimientos de seguridad y debería buscar otras vulnerabilidades comunes. La revisión puede incluir una combinación de busqueda automatizada de vulnerabilidades, pruebas de intrusión, análisis estático de código fuente y revisión de código por expertos.<br /> <br /> ;(d) Problemas encontrados : Los problemas de seguridad descubiertos serán reportados a el cliente y proveedor por igual. A todos los problemas se les dará seguimiento y serán reparados como se especifique en la sección de seguimiento de problemas de seguridad de este anexo.<br /> <br /> ===9. ADMINISTRACIÓN DE PROBLEMAS DE SEGURIDAD===<br /> <br /> ;(a) Identificación : El proveedor dara seguimiento a todos los problemas de seguridad descubiertos en todo el ciclo de desarrollo, ya sea un problema en los requerimientos, diseño, implementación, pruebas, publicación u operación. El riesgo asociado con cada problema de seguridad será evaluado, documentado y reportado a el cliente tan pronto como sea posible.<br /> <br /> ;(b) Protección : El proveedor protegerá apropiadamente la información relacionada a problemas de seguridad y la documentación relacionada a ellos, esto, para ayudar a disminuir la probabilidad de las vulnerabilidades en el software operacioneal del cliente sean expuestas.<br /> <br /> ;(c) Reparación : Los problemas de seguridad que sean indentificados antes de la entrega deben ser reparados por el proveedor. Los problemas de seguridad descubiertos despues de la entrega deben ser manejados en la misma manera que otros problemas funcionales según lo especificado en este contrato.<br /> <br /> ===10. CERTEZA===<br /> <br /> ;(a) Certeza : El proveedor proveera un &quot;paquete de certificación&quot; consistente en la documentación de seguridad creada a traves del proceso de desarrollo. El paquete deberá establecer que los requerimientos de seguridad, diseño, implementación y resultados de pruebas fueron completados apropiadamente y todos los problemas de seguridad fueron resueltos apropiadamente.<br /> <br /> ;(b) Auto-Certificación : El aquitecto de seguridad certificará que el software cumple con los requerimientos de seguridad, que todas las actividades de seguridad se realizaron, y que todos los problemas de seguridad identificados han sido documentados y resueltos. Cualquier excepción a el estado de la certificacion debe estar totalmente documentada al momento de la entrega.<br /> <br /> ;(c) No código malicioso : El proveedor garantize que el sofware no debe contener ningun código que no se alinee a algun requerimiento del software y debilite la seguridad de la aplicación, incluyendo viruses, gusanos, bombas de tiempo, puertas traseras, caballos de troya, huevos de pascua y cualquier otra forma de código malicioso.<br /> <br /> ===11. CONCENTIMIENTO Y MANTENIMIENTO DE LA SEGURIDAD===<br /> <br /> ;(a) Consentimiento : El software no debe ser considerado como aceptado hasta que el paquete de certificación este completo y todos los problemas de seguridad han sido resueltos.<br /> <br /> ;(b) Investigación de problemas de seguridad : Despues del concentimiento, si se sospecha (razonablemente) o descubren problemas de seguridad, el proveedor deberá asisitir al cliente en realizar una investigación para determinar la naturaleza del problema. El problema debe ser considerado &quot;nuevo&quot; si no es cubierto por los requerientos de seguridad y esta fuera de el alcance (razonable) de las pruebas de seguridad.<br /> <br /> ;(c) Problemas de seguridad nuevos : El proveedor y el cliente consientes en medir el alcance y esfuerzo requerido para resolver problemas de seguridad nuevos, y negociad de buena fe para alcanzar un acuerdo y realizar el trabajor requerido para solucionarlos.<br /> <br /> ;(d) Otros problemas de seguridad : El proveedor debe usar todos los esfuersos comercialmente rasonables consistentes con practicas de desarrollo comunes en la industria, tomando en cuenta la severidad de el riesgo, para resolver todos los problemas de seguridad considerados nuevos tan pronto como sea posible.<br /> <br /> [[Category:OWASP Legal Project]]<br /> <br /> __NOTOC__</div>

Jorge Correa https://wiki.owasp.org/index.php?title=Anexo_para_Contrato_de_Software_Seguro_de_OWASP&diff=79722 2010-03-12T13:43:24Z

<p>Jorge Correa: </p> <hr /> <div>'''ANEXO DE CONTRATO PARA DESAROLLO DE SOFTWARE SEGURO'''<br /> <br /> ADVERTENCIA: ESTE DOCUMENTO DEBE SER CONSIDERADO COMO UNA GUÍA SOLAMENTE.<br /> OWASP RECOMIENDA VEHEMENTEMENTE QUE CONSULTE UN ABOGADO CALIFICADO<br /> PARA AYUDARLE A NEGOCIAR UN CONTRATO DE SOFTWARE<br /> <br /> == Introducción ==<br /> <br /> Este anexo de contrato pretende ayudar a los proveedores de software y sus clientes a negociar y capturar importantes términos y condiciones contractuales relacionadas a la seguridad en el Software a ser desarrollado o entregado. La razon para este proyecto es que la mayoría de los contratos no mencionan estos temas, y las partes frecuentamente tienen puntos de vista dramaticamente diferentes a lo que en ralidad fue acordado. Creemos que articular claramente estos términos es la mejor manera de asegurarse que ambas partes pueden hacer desiciones informadas sobre como proceder. <br /> <br /> &quot;La seguridad del software comercial mejorará cuando el mercado demande mejor seguridad.<br /> Al menos, cada petición para propuestas de software debería pedir a los vendedores <br /> detallar como van ellos a probar sus productos para encotrar vulnerabilidades de<br /> seguridad. Este paso empezará convenciendo a los vendedores de software empaquetado<br /> y proveedores externos que las compañias valoran la seguridad.&quot;<br /> <br /> -- John Pescatore, Director de investiagacion con Gartner&lt;br&gt; <br /> <br /> Pedimos a los clientes y proveedores que usen este documento como un marco para discutir<br /> espectativas y negociar responsabilidades. Este anexo se creó para ser añadido a un<br /> contrato de desarrollo de software. Estos términos son negociables, significa que ellos<br /> pueden y deben ser discutidos por el cliente y el proveedor.<br /> <br /> == SOBRE EL PROYECTO ==<br /> <br /> Este documento fue creado por la fundación OWASP (Open Web Application Security Project por sus siglas en Inglés), una organización sin animo de lucro con el objetivo de crear herramientas y documentación, gratuita y abierta para asegurar software. Para facilitar su uso en contratación privada, este documento es de dominio publico. Puede encontrar detalles adicionales sobre este proyecto en http://www.owasp.com/index.php/OWASP_Legal_Project. Son Bienvenidos comentarios de ambos, productores y consumidores de software, asi como de la comunidad legal. <br /> <br /> OWASP reconoce gratamente la contribución especial de [http://www.aspectsecurity.com Aspect Security] por su rol en la investigación y preparación de este documento.<br /> <br /> ==OBJECIONES==<br /> <br /> Las siguientes páginas cubren algunas objeciones que escuchamos frecuentemente sobre usar este lenguaje en contratos de desarrollo de software:<br /> <br /> === PERO NO TODOS LOS TÉRMINOS SON CORRECTOS PARA NOSOTROS… ===<br /> <br /> Este documento debe ser considerado un punto de inicio para su contrato. Puede que no le gusten todas las actividades, o puede querer proponer mas. Puede querer asignar responsabilidades de manera diferente. Este documento no pretende capturar exactamente las necesidades de todos los clientes y proveedores de software. Pretende proveer un marco para discutir temas clave, importantes para asegurarse que el software se cree de forma segura. Despues de que tengan una discusión sobre seguridad y alcancen un acuerdo. Puede ajustar el convenio para que concuerde con el contrato.<br /> <br /> === PERO, ¿QUIEN DEBE PAGAR POR ESTAS ACTIVIDADES?… ===<br /> <br /> Este contrato no es sobre poner mas peso al desarollo de software. La pregunta no es sobre si hay costos asociados con seguridad (por supuesto que hay). La pregunta correcta es qué actividades deberían hacerse por ambas partes para minimizar costos, y cuando deberían ocurrir. <br /> <br /> Este anexo no menciona (intensionalmente) sobre el detalle de quién debería pagar por la actividades descritas. Mientras muchas de estas actividades deben estar pasando ya, y son esperadas por muchos clientes, ellas no estan practicadas regularmente en la industria del software. La cuestion de quién paga (y cuándo) debe ser parte de la negociación. <br /> <br /> Calcular el costo de la seguridad es muy difícil. Auque hay costos asociados con realizar actividades de seguridad, hay también costos importantes asociados con ignorar estas actividades. Estamos convencidos el mejor costo-beneficio para desarrollar software es reducir la probabilidad de que fallas de seguridad sean introducidas y minimzar el tiempo entre introducir una falla y arreglarla. <br /> <br /> Una distición importante a hacer cuando calculamos costos es entre construir mecanismos de seguridad y las actividades para asegurarse que esos mecanismos sean correctos y efectivos. Intentar agregar mecanismoa al final de el ciclo de desarrollo puede causar serios problemas de diseño e incrementará el costo dramáticamente. Este convenio promueve decisiones sobre mecanismos para minimizar estos costos. Similarmente, esperar hasta justo antes de la puesta en producción para hacer actividades de aseguramiento, tales como revisión de código y pruebas de intrusión, tambien incrementaría los costos dramaticamente. Creemos que el mejor costo-beneficio para ganar certeza es poner un nivel constante de esfuerzo en el aseguramiento a través del ciclo de desarrollo.<br /> <br /> ===PERO EL NIVEL DE RIGOR ESTA INCORRECTO….===<br /> <br /> Este convenio asume que el software que esta siendo desarrollado es rasonablemente importante para una empresa grande o agencia de gobierno. Hemos seleccionado un &quot;nivel de rigor&quot; para el convenio que es alcanzable por la mayoria de las organizaciones proveedoras de software, e identificaría y manejaría los riesgos más comunes.<br /> <br /> Sin embargo, para el software que va a ser usado en aplicaciones críticas, como aplicaciones médicas, financieras o relacionadas con el ejército. Puede querer incrementar el nivel de rigor. Puede querer agregar revisiones, documentación y actividades adicionales de prueba. Puede querer mejorar el proceso de encontrar, diagnosticar y remediar vulnerabilidades. Para aplicaciones menos sensibles, puede desear reducir o remover actividades.<br /> <br /> ===PERO NOSOTROS NO PODEMOS ACEPTAR TANTO RIESGO…===<br /> Este convenio pretende facilitar la discusión sobre quien tomaría el riesgo por las vulnerabilidades de seguridad en el software. Por un lado del espectro, el cliente podria tomar todo el riesgo y el proveedor podria entregar código con muchas vulnerabilidades. Por el otro extremo, el proveedor podría tomar todo el riesgo y asumir la responsabilidad de entregar código perfecto. Ambos extremos son irrealizables.<br /> <br /> Actualmente, en este convenio, el proveedor toma el riesgo por problemas que sean descubiertos en los requerimientos o deben ser cubiertos por esfuerzos razonables en pruebas. Pero la remediación de &quot;nuevos&quot; problemas de seguridad tendría que ser pagado por el cliente. Creemos que este es un equilibrio funcional, ya que limita el riesgo adquirido por el proveedor y promueve obtener requerimientos de seguridad por anticipado. Pero hay muchas otras posibles soluciones a este problema. Por favor, dejenos saber si tiene sugerencias alternas, podriamos incluirlas en versiones futuras de este documento.<br /> <br /> Note que la discusión aqui solo cubre el riesgo asociado con arreglar las vulnerabilidades de seguridad en el código, y no incluye los costos asociados con recuperarse de incidentes de seguridad relacionados con explotar cualquiera de esas vulnerabilidades. Estamos interesados en mejores prácticas en esta area.<br /> <br /> ===PERO COMO PODEMOS ASEGURAR CÓDIGO DE TERCEROS…===<br /> <br /> Casi todos los proyectos de sofware tienen una cantidad importante de código de terceros como librarieas, frameworks y productos. Desde la perspectiva de seguridad, este código es tan importante como el código desarrollado a la medida para su proyecto.<br /> Creemos que la responsabilidad de asegurar la seguridad de este código es llevada mejor por el proveedor, aunque ellos podrían no tener toda la capacidad para garantizar la seguridad por ellos mismos. Sin embargo, La seguridad puede ser parte de el la desición de &quot;construir o comprar&quot;, y esta parece ser la mejor manera de promoverla.<br /> <br /> El proveedor, por supuesto, tiene la opción de pasar la responsabilidad a el proveedor del software de terceros. El desarrolador puede tambien analizar el código de terceros por él mismo o contratar expertos en seguridad para analizarlo por él.<br /> <br /> ===PERO PORQUE DEBO PASAR POR TODO ESTE PROBLEMA…===<br /> <br /> En última instancia, creemos que no hay alternativa para hacer de la seguridad una parte de el proceso de contratación de software. Actualmente, creemos que hay serios malentendidos sobre la seguridad del código que esta siendo desarrollado bajo muchos contratos de desarrollo de software. Esto puede solamente llevar a una cara litigación y a desiciones hechas por individuos con poca experiencia y entendimiento sobre software. Lea el [[Secure software contracting hypothetical case study | Caso de estudio hipotético sobre contratación de software seguro]] para una discusión completa de este problema.<br /> <br /> Hay muchos beneficios al trabajar con este convenio. El principal es que pondrá claras las expectativas entre las partes involucradas. En algunos casos ayudará a evitar demandas cuando problemas de seguridad difíciles aparecen en el software. Tambien, estan son las mismas actividades requeridas por muchas razónes legales y de conformidad con estándares/leyes.<br /> <br /> ===PERO ES MUY DIFÍCIL PRODUCIR TODA ESTA DOCUMENTACIÓN…===<br /> <br /> OWASP no promueve la documentacion por la simpre documentacion. Este convenio esta enfocado en promover la calidad, no la cantidad. Creemos que puede ser posible (en algunos proyectos) cumplir con este contrato con una pequeña evaluacion de riesgo, algunas páginas de requerimientos, un pequeño documento de diseño de seguridad, un plan de pruebas, y algunos resultados de pruebas.<br /> <br /> El objetivo de esta documentación es simplemente asegurar, en cada etapa del desarrollo de software, que se ha puesto la atención apropiada en la seguridad. Un beneficio adiciona es que esta documentacion puede ser recolectada en conjunto para formar un &quot;paquete de certificación&quot; que básicamente esbose el argumento de porque deberiamos confiar que el software hará lo que dice.<br /> <br /> ==ANEXO DE CONTRATO==<br /> <br /> ===1. INTRODUCCIÓN===<br /> <br /> Esta anexo esta hecho para _____________________ (&quot;convenio&quot;) entre el Cliente y el proveedor. Tanto el Cliente como el proveedor acuerdan maximisar la seguridad del software de acuerdo a los siguientes términos.<br /> <br /> <br /> ===2. FILOSOFÍA===<br /> <br /> Esta anexo pretende aclarar los derechos y obligaciones relacionados a seguridad de todas las partes en una relacion de desarrollo de software. Al mayor nivel, las partes acuerdan que:<br /> <br /> ;(a) Las desiciones de seguridad estarán basadas en el riesgo : Las desciciones sobre la seguridad seran tomadas en conunto por el cliente y el proveedor basandose en un firme entendimiento de el riesgo involucrado. <br /> <br /> ;(b) Las actividades de seguridad estarán balanceadas : El esfurzo de seguridad será distribuido equitativamente a través de todo el ciclo de desarollo de software.<br /> <br /> ;(c) Las actividades de seguridad estarán integradas : Todas las actividades y documentación discutidas aqui pueden y deben ser integradas dentro del ciclo de desarrollo de software del proveedor y no mantenerse separadas de el resto del proyecto. Nada en este anexo implica algún processo de desarrollo de software en particular.<br /> <br /> ;(d) Se esperan vulnerabilidades : Todo software contiene defectos, y algunos de estos crearan problemas de seguridad. Ambos, cliente y proveedor se esforzará para identificar las vulnerabilidades tan pronto como sea posible en el ciclo de desarrollo.<br /> <br /> ;(e) La información sobre seguridad será comunicada por completo : Toda la información relevante para la seguridad se compartirá entre el cliente y el proveedor inmediatamente y completamente.<br /> <br /> ;(f) Se requerirá solo documentacion de seguridad necesaria : La documentación de seguridad no necesita ser demasiado amplia para describir claramente el diseño de seguridad, análisis de riesgo y problemas.<br /> <br /> ===3. ACTIVIDADES EN EL CICLO DE DESARROLLO===<br /> <br /> ;(a) Entendimiento del Riesgo : El proveedor y el cliente acuerdan trabajar juntos para entender y documentar los riesgos que enfrenta la aplicacion. Este esfuerzo debe identificar los riesgos clave para los activos y funciones importantes que provee la aplicación. Cada uno de los temas listados en la sección de requerimientos debe ser considerado.<br /> <br /> ;(b) Requerimientos : Basado en los riesgos, El proveedor y cliente acuerda trabajar juntos para crear requerimientos de seguridad detallados como parte de la especificacion de el software a ser desarrollado. Cada uno de los temas listados en la sección de requerimientos de este anexo deben ser discutidos y evaluados por ambos, cliente y proveedor. Estos requerimientos pueden ser satisfechos por software creado a la medida, software de terceros, o la plataforma. <br /> <br /> ;(c) Diseño : el desarollador acuerda proveer documentation que explique claramente el diseño para adquirir cada uno de los requerimientos de seguridad. En muchos de los casos, esta documentacion describirá los mecanismos de seguridad, donde se incluiran dentro de la arquitectura, y todos los patrones de diseño relevantes para asegurar su uso adecuado. El diseño debe especificar claramente si tales mecanismos vienen de software a la medida, software de terceros o de la plataforma.<br /> <br /> ;(d) Implementación : El proveedor acuerda entregar y seguir un conjunto de lineamientos de codificación segura. Estos lineamientos indicarán como sele de debe dar formato, estructurar y comentar el código fuente. Todo código relacionado a seguridad debe ser comentado profundamente. Guías sobre como evitar vulnerabilidades se seguridad comunes debe ser incluida. Tambien, todo el código debe ser revisado por al menos otro desarollador basandose en los requerimientos de seguridad y los lineamientos de codificación antes de ser conciderado listo para pruebas unitarias.<br /> <br /> ;(e) Pruebas y análisis de seguridad : El proveedor acuerda entregar y seguir un plan de pruebas de seguridad que defina como se realizarán las pruebas o bien establecer como cada uno de los requerimientos de seguridad va a ser complido. El nivel de rigor de esta actividad debe ser considerado y detallado en un plan. El proveedor ejecutará el plan de prueba y proveera los resultados a el cliente.<br /> <br /> ;(f) Publicación segura : El proveedor acuerda entregar lineamientos de configuración segura que describan completamente todas las opciones de configuracion relacionadas con seguridad y sus implicaciones para la seguridad del software en su conjunto. Los lineamientos deben incluir una descripción completa de las dependencias en la plataforma y como deben ser configuradas de manera segura, incluidas las del sistema operativo, servidor Web y servidor de aplicacion. La configuracion predeterminada del software debe ser segura.<br /> <br /> ===4. ÁREAS CON REQUERIMIENTOS DE SEGURIDAD===<br /> <br /> Los siguientes temas/áreas deben ser considerados durante las actividades de entendimiento de riesgo y definición de requerimientos. Este esfuerzo debe producir un conjunto de requerimientos ajustados, especificos y probables. Ambos, proveedor y cliente deben ser involucrados en este proceso y deben ponerse de acuerdo sobre el conjunto final de requerimientos.<br /> <br /> ;(a) Validación de entradas y condificación : Los requerimientos deben especificar las reglas para canonicalización, validación y codificación de cada dato de entrada a la aplicación, ya sea de usuarios, sistemas de archivos, bases de datos o sistemas externos. La regla predeterminada debe ser que todas las entradas sean validadas a menos que cumplan con una especificacion detallada de que esta permitido. Además, los requerimientos deben especificar las acciones a tomar cuando se reciven entradas no válidas. Especificamente, la aplicación no debe ser susceptible a inyecciones, desbordamientos, manipulación y otros ataques con entradas de usuario corruptas.<br /> <br /> ;(b) Autentificación y manejo de sessiones : Los requerimientos deben especificar como se protegeran las credenciales para autentificación y los identificadores de sesión a través del ciclo de desarrollo de software. Los requerimientos para todas las funciones relacionadas deben ser agregadas incluyendo recuperar contraseñas, cambio de contraseñas, recordar contraseñas, desconexión y conexión multiple.<br /> <br /> ;(c) Control de Acceso : Los requerimientos deben incluir una descripcion detallada de todos los roles (grupos, privilegios, autorizaciones) usadas en la aplicación. Los requerimientos deben indicar todos los activos y funciones que provee la aplicacion. Los requerimientos deben especificar detallada y exactamente los derechos de acceso para cualquier activo y función de cada rol. Se sugiere utilizar un formato de matriz de control de acceso para documentar estas reglas.<br /> <br /> ;(d) Manejo de Errores : Los requerimientos deben detallar como se van a manejar los errores que ocurran dentro del procesamiento. Algunas aplicaciones deberían hacer lo mejor posible en caso de un error, mientras que otras deberían terminar su procesamiento inmediatamente.<br /> <br /> ;(e) Historial : Los requerimientos deben especificar que eventos son relevantes para la seguridad y necesitan ser registrados, como ataques detectados, intentos de conexión fallidos e intentos de exeder la autorización. Los requerimientos deben especificar tambien que information registrar con cada evento, incluyendo hora y fecha, descripción del evento, detalles de aplicación, y otra información útil en esfuerzos forences.<br /> <br /> ;(f) Conexiones a sistemas externos : Los requerimientos deben especifica como la autentificación y cifrado será manejado para todos los systemas externos, tales como bases de datos, directorios y servicios Web. Todas las credenciales requeridas para la comunicación con sistemas externos deben almacenarce cifradas y fuera de el código dentro de archivos de configuración. <br /> <br /> ;(g) Cifrado : Los requerimientos deben especificar que datos deben ser cifrados, como serán cifrados y como todos los certificados y otras credenciales deben ser manejadas. Las aplicaciones deben usar algoritmos estándar implementados en una librerias de cifrado que hayan sido usadas y probadas ampliamente.<br /> <br /> ;(h) Disponibilidad : Los requerimientos deben especificar como protegerse de ataques de negación de servicio. Todos los posibles ataques en la aplicacion deben ser considerados, incluyendo bloqueos de auntentificación, agotamiento de conexiones y otros ataques de agotamiento de recursos.<br /> <br /> ;(i) Configuración segura : Los requerimientos deben especificar que los valores predeterminados para todas las configuraciones relacionadas a seguridad deben ser seguras. Para propósitos de auditoría, el software deberia ser capás de producir un reporte sencillo de leer que muestre los detalles de todas las configuraciones relacionadas con seguridad.<br /> <br /> ;(j) Vulnerabilidades especificas : Los requerimientos deben incluir un conjunto de vulnerabilidades especificas que no deben estar presentes en el software. A menos que sea especificado de otra manera, el software no debe incluir ninguna de las fallas descritas en el la &quot;Lista de OWASP sobre las 10 vulnerabilidades mas críticas en aplicaciones Web&quot;.<br /> <br /> ===5. PERSONAL Y ORGANIZACIÓN===<br /> <br /> ;(a) Arquitecto en seguridad : El desarollador asignará la responsabilidad por la seguridad a un solo recurso técnico experimentado, para ser conocido como el arquitecto de seguridad del proyecto. El arquitecto de seguridad certificará la seguridad de cada entregable.<br /> <br /> ;(b) Entrenamiento en Seguridad : el proveedor será responsable de verificar que todos los miembros del equipo de desarrollo han sido entrenados en tecnicas de programación segura.<br /> <br /> ;(c) Desarrolladores dignos de confianza : El proveedor acuerda realizar las investigaciones de antecendentes apropiadas a todos los miembros del equipo de desarrollo.<br /> <br /> ===6. AMBIENTE DE DESARROLLO===<br /> <br /> ;(a) Codificación segura : El proveedor debe mencionar que herramientas se usarán en el ambiente de desarrollo de software para promover la codificación segura.<br /> <br /> ;(b) Adminstración de configuración : El proveedor debe usar un sistema de control de versiones que autentifique y registre el miembro del equipo asociado con todos los cambios en el código base, todos los archivos de configuración y compilación.<br /> <br /> ;(c) Distribución : El proveedor debe usar un proceso de compilación que construya confiablemente un archivo de distribución completo desde el código fuente. Este proceso debe incluir un método para verificar la integridad de el software entregado al cliente.<br /> <br /> ===7. LIBRERIAS, MARCOS DE DESARROLLO Y PRODUCTOS===<br /> <br /> ;(a) Apertura : El proveedor debe mencionar todas los aplicaciones de terceros usadas en el software, incluyendo todas las librerias, marcos de desarrollo, componentes y otros productos, ya sean comerciales, gratuitos, de código abierto o código cerrado.<br /> <br /> ;(b) Evaluación : El proveedor debe hacer esfuerzos rasonables para asegurar que el sofware de terceros cumple con todos los términos de este contrato y es tan seguro como el código a la medida desarrollado bajo este contrato.<br /> <br /> ===8. REVISIONES DE SEGURIDAD===<br /> <br /> ;(a) Derecho de revisión : El cliente tiene el derecho mandar revisar el software para buscar fallas de seguridad, esto a sus expesas y en cualquier momento dentro de los 60 dias despues de la entrega. El desarrollador acepta proveer apoyo rasonable al equipo de revisión proveyendo el codigo fuente y acceso a los ambientes de pruebas.<br /> <br /> ;(b) Covertura de la revisión : Las revisiones de seguridad deben cubrir todos los aspectos de el software entregado, incluyendo código a la medida, componentes, productos y configuración de sistema.<br /> <br /> ;(c) Alcance de la revisión : Al menos, la revisión debe cubrir todos los requerimientos de seguridad y debería buscar otras vulnerabilidades comunes. La revisión puede incluir una combinación de busqueda automatizada de vulnerabilidades, pruebas de intrusión, análisis estático de código fuente y revisión de código por expertos.<br /> <br /> ;(d) Problemas encontrados : Los problemas de seguridad descubiertos serán reportados a el cliente y proveedor por igual. A todos los problemas se les dará seguimiento y serán reparados como se especifique en la sección de seguimiento de problemas de seguridad de este anexo.<br /> <br /> ===9. ADMINISTRACIÓN DE PROBLEMAS DE SEGURIDAD===<br /> <br /> ;(a) Identificación : El proveedor dara seguimiento a todos los problemas de seguridad descubiertos en todo el ciclo de desarrollo, ya sea un problema en los requerimientos, diseño, implementación, pruebas, publicación u operación. El riesgo asociado con cada problema de seguridad será evaluado, documentado y reportado a el cliente tan pronto como sea posible.<br /> <br /> ;(b) Protección : El proveedor protegerá apropiadamente la información relacionada a problemas de seguridad y la documentación relacionada a ellos, esto, para ayudar a disminuir la probabilidad de las vulnerabilidades en el software operacioneal del cliente sean expuestas.<br /> <br /> ;(c) Reparación : Los problemas de seguridad que sean indentificados antes de la entrega deben ser reparados por el proveedor. Los problemas de seguridad descubiertos despues de la entrega deben ser manejados en la misma manera que otros problemas funcionales según lo especificado en este contrato.<br /> <br /> ===10. CERTEZA===<br /> <br /> ;(a) Certeza : El proveedor proveera un &quot;paquete de certificación&quot; consistente en la documentación de seguridad creada a traves del proceso de desarrollo. El paquete deberá establecer que los requerimientos de seguridad, diseño, implementación y resultados de pruebas fueron completados apropiadamente y todos los problemas de seguridad fueron resueltos apropiadamente.<br /> <br /> ;(b) Auto-Certificación : El aquitecto de seguridad certificará que el software cumple con los requerimientos de seguridad, que todas las actividades de seguridad se realizaron, y que todos los problemas de seguridad identificados han sido documentados y resueltos. Cualquier excepción a el estado de la certificacion debe estar totalmente documentada al momento de la entrega.<br /> <br /> ;(c) No código malicioso : El proveedor garantize que el sofware no debe contener ningun código que no se alinee a algun requerimiento del software y debilite la seguridad de la aplicación, incluyendo viruses, gusanos, bombas de tiempo, puertas traseras, caballos de troya, huevos de pascua y cualquier otra forma de código malicioso.<br /> <br /> ===11. CONCENTIMIENTO Y MANTENIMIENTO DE LA SEGURIDAD===<br /> <br /> ;(a) Consentimiento : El software no debe ser considerado como aceptado hasta que el paquete de certificación este completo y todos los problemas de seguridad han sido resueltos.<br /> <br /> ;(b) Investigación de problemas de seguridad : Despues del concentimiento, si se sospecha (razonablemente) o descubren problemas de seguridad, el proveedor deberá asisitir al cliente en realizar una investigación para determinar la naturaleza del problema. El problema debe ser considerado &quot;nuevo&quot; si no es cubierto por los requerientos de seguridad y esta fuera de el alcance (razonable) de las pruebas de seguridad.<br /> <br /> ;(c) Problemas de seguridad nuevos : El proveedor y el cliente consientes en medir el alcance y esfuerzo requerido para resolver problemas de seguridad nuevos, y negociad de buena fe para alcanzar un acuerdo y realizar el trabajor requerido para solucionarlos.<br /> <br /> ;(d) Otros problemas de seguridad : El proveedor debe usar todos los esfuersos comercialmente rasonables consistentes con practicas de desarrollo comunes en la industria, tomando en cuenta la severidad de el riesgo, para resolver todos los problemas de seguridad considerados nuevos tan pronto como sea posible.<br /> <br /> [[Category:OWASP Legal Project]]<br /> <br /> __NOTOC__</div>

Jorge Correa https://wiki.owasp.org/index.php?title=Anexo_para_Contrato_de_Software_Seguro_de_OWASP&diff=79721 2010-03-12T13:40:21Z

<p>Jorge Correa: </p> <hr /> <div>'''ANEXO DE CONTRATO PARA DESAROLLO DE SOFTWARE SEGURO'''<br /> <br /> ADVERTENCIA: ESTE DOCUMENTO DEBE SER CONSIDERADO COMO UNA GUÍA SOLAMENTE.<br /> OWASP RECOMIENDA VEHEMENTEMENTE QUE CONSULTE UN ABOGADO CALIFICADO<br /> PARA AYUDARLE A NEGOCIAR UN CONTRATO DE SOFTWARE<br /> <br /> == Introducción ==<br /> <br /> Este anexo de contrato pretende ayudar a los proveedores de software y sus clientes a negociar y capturar importantes términos y condiciones contractuales relacionadas a la seguridad en el Software a ser desarrollado o entregado. La razon para este proyecto es que la mayoría de los contratos no mencionan estos temas, y las partes frecuentamente tienen puntos de vista dramaticamente diferentes a lo que en ralidad fue acordado. Creemos que articular claramente estos términos es la mejor manera de asegurarse que ambas partes pueden hacer desiciones informadas sobre como proceder. <br /> <br /> &quot;La seguridad del software comercial mejorará cuando el mercado demande mejor seguridad.<br /> Al menos, cada petición para propuestas de software debería pedir a los vendedores <br /> detallar como van ellos a probar sus productos para encotrar vulnerabilidades de<br /> seguridad. Este paso empezará convenciendo a los vendedores de software empaquetado<br /> y proveedores externos que las compañias valoran la seguridad.&quot;<br /> <br /> -- John Pescatore, Director de investiagacion con Gartner&lt;br&gt; <br /> <br /> Pedimos a los clientes y proveedores que usen este documento como un marco para discutir<br /> espectativas y negociar responsabilidades. Este anexo se creó para ser añadido a un<br /> contrato de desarrollo de software. Estos términos son negociables, significa que ellos<br /> pueden y deben ser discutidos por el cliente y el proveedor.<br /> <br /> == SOBRE EL PROYECTO ==<br /> <br /> Este documento fue creado por la fundación OWASP (Open Web Application Security Project por sus siglas en Inglés), una organización sin animo de lucro con el objetivo de crear herramientas y documentación, gratuita y abierta para asegurar software. Para facilitar su uso en contratación privada, este documento es de dominio publico. Puede encontrar detalles adicionales sobre este proyecto en http://www.owasp.com/index.php/OWASP_Legal_Project. Son Bienvenidos comentarios de ambos, productores y consumidores de software, asi como de la comunidad legal. <br /> <br /> OWASP reconoce gratamente la contribución especial de [http://www.aspectsecurity.com Aspect Security] por su rol en la investigación y preparación de este documento.<br /> <br /> ==OBJECIONES==<br /> <br /> Las siguientes páginas cubren algunas objeciones que escuchamos frecuentemente sobre usar este lenguaje en contratos de desarrollo de software:<br /> <br /> === PERO NO TODOS LOS TÉRMINOS SON CORRECTOS PARA NOSOTROS… ===<br /> <br /> Este documento debe ser considerado un punto de inicio para su contrato. Puede que no le gusten todas las actividades, o puede querer proponer mas. Puede querer asignar responsabilidades de manera diferente. Este documento no pretende capturar exactamente las necesidades de todos los clientes y proveedores de software. Pretende proveer un marco para discutir temas clave, importantes para asegurarse que el software se cree de forma segura. Despues de que tengan una discusión sobre seguridad y alcancen un acuerdo. Puede ajustar el convenio para que concuerde con el contrato.<br /> <br /> ===PERO, ¿QUIEN DEBE PAGAR POR ESTAS ACTIVIDADES?…===<br /> <br /> Este contrato no es sobre poner mas peso al desarollo de software. La pregunta no es sobre si hay costos asociados con seguridad (por supuesto que hay). Sino, la pregunta correcta es que actividades deberían hacerse por ambas partes para minimizar costos, y cuando deberían ocurrir.<br /> <br /> Este anexo no menciona (intensionalmente) sobre el detalle de quien debería pagar por la actividades descritas. Mientras muchas de estas actividades deben estar pasando ya, y son esperadas por muchos clientes, ellas no estan practicadas regularmente en la industria del software. La cuestion de quien paga (y cuando) debe ser parte de la negociación.<br /> <br /> Calcular el costo de la seguridad es muy difícil. Auque hay costos asociados con realizar actividades de seguridad, hay también costos importantes asociados con ignorar estas actividades. Estamos convencidos el mejor costo-beneficio para desarrollar software es reducir la probabilidad de que fallas de seguridad sean introducidas y minimzar el tiempo entre introducir una falla y arreglarla.<br /> <br /> Una distición importante a hacer cuando calculamos costos es entre construir mecanismos de seguridad y las actividades para asegurarse que esos mecanismos sean correctos y efectivos. Intentar agregar mecanismoa al final de el ciclo de desarrollo puede causar serios problemas de diseño e incrementará el costo dramáticamente. Este convenio promieve decisiones sobre mecanismos para minimizar estos costos. Similarmente, esperas hasta justo antes de la publicación para hacer actividades de aseguramiento, tales como revisión de código y pruebas de intrudión, tambien incrementaría los costos dramaticamente. Creemos que el mejor costo-beneficio para ganar certeza es poner un nivel constante de esfuerzo en el aseguramiento a través del ciclo de desarrollo.<br /> <br /> ===PERO EL NIVEL DE RIGOR ESTA INCORRECTO….===<br /> <br /> Este convenio asume que el software que esta siendo desarrollado es rasonablemente importante para una empresa grande o agencia de gobierno. Hemos seleccionado un &quot;nivel de rigor&quot; para el convenio que es alcanzable por la mayoria de las organizaciones proveedoras de software, e identificaría y manejaría los riesgos más comunes.<br /> <br /> Sin embargo, para el software que va a ser usado en aplicaciones críticas, como aplicaciones médicas, financieras o relacionadas con el ejército. Puede querer incrementar el nivel de rigor. Puede querer agregar revisiones, documentación y actividades adicionales de prueba. Puede querer mejorar el proceso de encontrar, diagnosticar y remediar vulnerabilidades. Para aplicaciones menos sensibles, puede desear reducir o remover actividades.<br /> <br /> ===PERO NOSOTROS NO PODEMOS ACEPTAR TANTO RIESGO…===<br /> Este convenio pretende facilitar la discusión sobre quien tomaría el riesgo por las vulnerabilidades de seguridad en el software. Por un lado del espectro, el cliente podria tomar todo el riesgo y el proveedor podria entregar código con muchas vulnerabilidades. Por el otro extremo, el proveedor podría tomar todo el riesgo y asumir la responsabilidad de entregar código perfecto. Ambos extremos son irrealizables.<br /> <br /> Actualmente, en este convenio, el proveedor toma el riesgo por problemas que sean descubiertos en los requerimientos o deben ser cubiertos por esfuerzos razonables en pruebas. Pero la remediación de &quot;nuevos&quot; problemas de seguridad tendría que ser pagado por el cliente. Creemos que este es un equilibrio funcional, ya que limita el riesgo adquirido por el proveedor y promueve obtener requerimientos de seguridad por anticipado. Pero hay muchas otras posibles soluciones a este problema. Por favor, dejenos saber si tiene sugerencias alternas, podriamos incluirlas en versiones futuras de este documento.<br /> <br /> Note que la discusión aqui solo cubre el riesgo asociado con arreglar las vulnerabilidades de seguridad en el código, y no incluye los costos asociados con recuperarse de incidentes de seguridad relacionados con explotar cualquiera de esas vulnerabilidades. Estamos interesados en mejores prácticas en esta area.<br /> <br /> ===PERO COMO PODEMOS ASEGURAR CÓDIGO DE TERCEROS…===<br /> <br /> Casi todos los proyectos de sofware tienen una cantidad importante de código de terceros como librarieas, frameworks y productos. Desde la perspectiva de seguridad, este código es tan importante como el código desarrollado a la medida para su proyecto.<br /> Creemos que la responsabilidad de asegurar la seguridad de este código es llevada mejor por el proveedor, aunque ellos podrían no tener toda la capacidad para garantizar la seguridad por ellos mismos. Sin embargo, La seguridad puede ser parte de el la desición de &quot;construir o comprar&quot;, y esta parece ser la mejor manera de promoverla.<br /> <br /> El proveedor, por supuesto, tiene la opción de pasar la responsabilidad a el proveedor del software de terceros. El desarrolador puede tambien analizar el código de terceros por él mismo o contratar expertos en seguridad para analizarlo por él.<br /> <br /> ===PERO PORQUE DEBO PASAR POR TODO ESTE PROBLEMA…===<br /> <br /> En última instancia, creemos que no hay alternativa para hacer de la seguridad una parte de el proceso de contratación de software. Actualmente, creemos que hay serios malentendidos sobre la seguridad del código que esta siendo desarrollado bajo muchos contratos de desarrollo de software. Esto puede solamente llevar a una cara litigación y a desiciones hechas por individuos con poca experiencia y entendimiento sobre software. Lea el [[Secure software contracting hypothetical case study | Caso de estudio hipotético sobre contratación de software seguro]] para una discusión completa de este problema.<br /> <br /> Hay muchos beneficios al trabajar con este convenio. El principal es que pondrá claras las expectativas entre las partes involucradas. En algunos casos ayudará a evitar demandas cuando problemas de seguridad difíciles aparecen en el software. Tambien, estan son las mismas actividades requeridas por muchas razónes legales y de conformidad con estándares/leyes.<br /> <br /> ===PERO ES MUY DIFÍCIL PRODUCIR TODA ESTA DOCUMENTACIÓN…===<br /> <br /> OWASP no promueve la documentacion por la simpre documentacion. Este convenio esta enfocado en promover la calidad, no la cantidad. Creemos que puede ser posible (en algunos proyectos) cumplir con este contrato con una pequeña evaluacion de riesgo, algunas páginas de requerimientos, un pequeño documento de diseño de seguridad, un plan de pruebas, y algunos resultados de pruebas.<br /> <br /> El objetivo de esta documentación es simplemente asegurar, en cada etapa del desarrollo de software, que se ha puesto la atención apropiada en la seguridad. Un beneficio adiciona es que esta documentacion puede ser recolectada en conjunto para formar un &quot;paquete de certificación&quot; que básicamente esbose el argumento de porque deberiamos confiar que el software hará lo que dice.<br /> <br /> ==ANEXO DE CONTRATO==<br /> <br /> ===1. INTRODUCCIÓN===<br /> <br /> Esta anexo esta hecho para _____________________ (&quot;convenio&quot;) entre el Cliente y el proveedor. Tanto el Cliente como el proveedor acuerdan maximisar la seguridad del software de acuerdo a los siguientes términos.<br /> <br /> <br /> ===2. FILOSOFÍA===<br /> <br /> Esta anexo pretende aclarar los derechos y obligaciones relacionados a seguridad de todas las partes en una relacion de desarrollo de software. Al mayor nivel, las partes acuerdan que:<br /> <br /> ;(a) Las desiciones de seguridad estarán basadas en el riesgo : Las desciciones sobre la seguridad seran tomadas en conunto por el cliente y el proveedor basandose en un firme entendimiento de el riesgo involucrado. <br /> <br /> ;(b) Las actividades de seguridad estarán balanceadas : El esfurzo de seguridad será distribuido equitativamente a través de todo el ciclo de desarollo de software.<br /> <br /> ;(c) Las actividades de seguridad estarán integradas : Todas las actividades y documentación discutidas aqui pueden y deben ser integradas dentro del ciclo de desarrollo de software del proveedor y no mantenerse separadas de el resto del proyecto. Nada en este anexo implica algún processo de desarrollo de software en particular.<br /> <br /> ;(d) Se esperan vulnerabilidades : Todo software contiene defectos, y algunos de estos crearan problemas de seguridad. Ambos, cliente y proveedor se esforzará para identificar las vulnerabilidades tan pronto como sea posible en el ciclo de desarrollo.<br /> <br /> ;(e) La información sobre seguridad será comunicada por completo : Toda la información relevante para la seguridad se compartirá entre el cliente y el proveedor inmediatamente y completamente.<br /> <br /> ;(f) Se requerirá solo documentacion de seguridad necesaria : La documentación de seguridad no necesita ser demasiado amplia para describir claramente el diseño de seguridad, análisis de riesgo y problemas.<br /> <br /> ===3. ACTIVIDADES EN EL CICLO DE DESARROLLO===<br /> <br /> ;(a) Entendimiento del Riesgo : El proveedor y el cliente acuerdan trabajar juntos para entender y documentar los riesgos que enfrenta la aplicacion. Este esfuerzo debe identificar los riesgos clave para los activos y funciones importantes que provee la aplicación. Cada uno de los temas listados en la sección de requerimientos debe ser considerado.<br /> <br /> ;(b) Requerimientos : Basado en los riesgos, El proveedor y cliente acuerda trabajar juntos para crear requerimientos de seguridad detallados como parte de la especificacion de el software a ser desarrollado. Cada uno de los temas listados en la sección de requerimientos de este anexo deben ser discutidos y evaluados por ambos, cliente y proveedor. Estos requerimientos pueden ser satisfechos por software creado a la medida, software de terceros, o la plataforma. <br /> <br /> ;(c) Diseño : el desarollador acuerda proveer documentation que explique claramente el diseño para adquirir cada uno de los requerimientos de seguridad. En muchos de los casos, esta documentacion describirá los mecanismos de seguridad, donde se incluiran dentro de la arquitectura, y todos los patrones de diseño relevantes para asegurar su uso adecuado. El diseño debe especificar claramente si tales mecanismos vienen de software a la medida, software de terceros o de la plataforma.<br /> <br /> ;(d) Implementación : El proveedor acuerda entregar y seguir un conjunto de lineamientos de codificación segura. Estos lineamientos indicarán como sele de debe dar formato, estructurar y comentar el código fuente. Todo código relacionado a seguridad debe ser comentado profundamente. Guías sobre como evitar vulnerabilidades se seguridad comunes debe ser incluida. Tambien, todo el código debe ser revisado por al menos otro desarollador basandose en los requerimientos de seguridad y los lineamientos de codificación antes de ser conciderado listo para pruebas unitarias.<br /> <br /> ;(e) Pruebas y análisis de seguridad : El proveedor acuerda entregar y seguir un plan de pruebas de seguridad que defina como se realizarán las pruebas o bien establecer como cada uno de los requerimientos de seguridad va a ser complido. El nivel de rigor de esta actividad debe ser considerado y detallado en un plan. El proveedor ejecutará el plan de prueba y proveera los resultados a el cliente.<br /> <br /> ;(f) Publicación segura : El proveedor acuerda entregar lineamientos de configuración segura que describan completamente todas las opciones de configuracion relacionadas con seguridad y sus implicaciones para la seguridad del software en su conjunto. Los lineamientos deben incluir una descripción completa de las dependencias en la plataforma y como deben ser configuradas de manera segura, incluidas las del sistema operativo, servidor Web y servidor de aplicacion. La configuracion predeterminada del software debe ser segura.<br /> <br /> ===4. ÁREAS CON REQUERIMIENTOS DE SEGURIDAD===<br /> <br /> Los siguientes temas/áreas deben ser considerados durante las actividades de entendimiento de riesgo y definición de requerimientos. Este esfuerzo debe producir un conjunto de requerimientos ajustados, especificos y probables. Ambos, proveedor y cliente deben ser involucrados en este proceso y deben ponerse de acuerdo sobre el conjunto final de requerimientos.<br /> <br /> ;(a) Validación de entradas y condificación : Los requerimientos deben especificar las reglas para canonicalización, validación y codificación de cada dato de entrada a la aplicación, ya sea de usuarios, sistemas de archivos, bases de datos o sistemas externos. La regla predeterminada debe ser que todas las entradas sean validadas a menos que cumplan con una especificacion detallada de que esta permitido. Además, los requerimientos deben especificar las acciones a tomar cuando se reciven entradas no válidas. Especificamente, la aplicación no debe ser susceptible a inyecciones, desbordamientos, manipulación y otros ataques con entradas de usuario corruptas.<br /> <br /> ;(b) Autentificación y manejo de sessiones : Los requerimientos deben especificar como se protegeran las credenciales para autentificación y los identificadores de sesión a través del ciclo de desarrollo de software. Los requerimientos para todas las funciones relacionadas deben ser agregadas incluyendo recuperar contraseñas, cambio de contraseñas, recordar contraseñas, desconexión y conexión multiple.<br /> <br /> ;(c) Control de Acceso : Los requerimientos deben incluir una descripcion detallada de todos los roles (grupos, privilegios, autorizaciones) usadas en la aplicación. Los requerimientos deben indicar todos los activos y funciones que provee la aplicacion. Los requerimientos deben especificar detallada y exactamente los derechos de acceso para cualquier activo y función de cada rol. Se sugiere utilizar un formato de matriz de control de acceso para documentar estas reglas.<br /> <br /> ;(d) Manejo de Errores : Los requerimientos deben detallar como se van a manejar los errores que ocurran dentro del procesamiento. Algunas aplicaciones deberían hacer lo mejor posible en caso de un error, mientras que otras deberían terminar su procesamiento inmediatamente.<br /> <br /> ;(e) Historial : Los requerimientos deben especificar que eventos son relevantes para la seguridad y necesitan ser registrados, como ataques detectados, intentos de conexión fallidos e intentos de exeder la autorización. Los requerimientos deben especificar tambien que information registrar con cada evento, incluyendo hora y fecha, descripción del evento, detalles de aplicación, y otra información útil en esfuerzos forences.<br /> <br /> ;(f) Conexiones a sistemas externos : Los requerimientos deben especifica como la autentificación y cifrado será manejado para todos los systemas externos, tales como bases de datos, directorios y servicios Web. Todas las credenciales requeridas para la comunicación con sistemas externos deben almacenarce cifradas y fuera de el código dentro de archivos de configuración. <br /> <br /> ;(g) Cifrado : Los requerimientos deben especificar que datos deben ser cifrados, como serán cifrados y como todos los certificados y otras credenciales deben ser manejadas. Las aplicaciones deben usar algoritmos estándar implementados en una librerias de cifrado que hayan sido usadas y probadas ampliamente.<br /> <br /> ;(h) Disponibilidad : Los requerimientos deben especificar como protegerse de ataques de negación de servicio. Todos los posibles ataques en la aplicacion deben ser considerados, incluyendo bloqueos de auntentificación, agotamiento de conexiones y otros ataques de agotamiento de recursos.<br /> <br /> ;(i) Configuración segura : Los requerimientos deben especificar que los valores predeterminados para todas las configuraciones relacionadas a seguridad deben ser seguras. Para propósitos de auditoría, el software deberia ser capás de producir un reporte sencillo de leer que muestre los detalles de todas las configuraciones relacionadas con seguridad.<br /> <br /> ;(j) Vulnerabilidades especificas : Los requerimientos deben incluir un conjunto de vulnerabilidades especificas que no deben estar presentes en el software. A menos que sea especificado de otra manera, el software no debe incluir ninguna de las fallas descritas en el la &quot;Lista de OWASP sobre las 10 vulnerabilidades mas críticas en aplicaciones Web&quot;.<br /> <br /> ===5. PERSONAL Y ORGANIZACIÓN===<br /> <br /> ;(a) Arquitecto en seguridad : El desarollador asignará la responsabilidad por la seguridad a un solo recurso técnico experimentado, para ser conocido como el arquitecto de seguridad del proyecto. El arquitecto de seguridad certificará la seguridad de cada entregable.<br /> <br /> ;(b) Entrenamiento en Seguridad : el proveedor será responsable de verificar que todos los miembros del equipo de desarrollo han sido entrenados en tecnicas de programación segura.<br /> <br /> ;(c) Desarrolladores dignos de confianza : El proveedor acuerda realizar las investigaciones de antecendentes apropiadas a todos los miembros del equipo de desarrollo.<br /> <br /> ===6. AMBIENTE DE DESARROLLO===<br /> <br /> ;(a) Codificación segura : El proveedor debe mencionar que herramientas se usarán en el ambiente de desarrollo de software para promover la codificación segura.<br /> <br /> ;(b) Adminstración de configuración : El proveedor debe usar un sistema de control de versiones que autentifique y registre el miembro del equipo asociado con todos los cambios en el código base, todos los archivos de configuración y compilación.<br /> <br /> ;(c) Distribución : El proveedor debe usar un proceso de compilación que construya confiablemente un archivo de distribución completo desde el código fuente. Este proceso debe incluir un método para verificar la integridad de el software entregado al cliente.<br /> <br /> ===7. LIBRERIAS, MARCOS DE DESARROLLO Y PRODUCTOS===<br /> <br /> ;(a) Apertura : El proveedor debe mencionar todas los aplicaciones de terceros usadas en el software, incluyendo todas las librerias, marcos de desarrollo, componentes y otros productos, ya sean comerciales, gratuitos, de código abierto o código cerrado.<br /> <br /> ;(b) Evaluación : El proveedor debe hacer esfuerzos rasonables para asegurar que el sofware de terceros cumple con todos los términos de este contrato y es tan seguro como el código a la medida desarrollado bajo este contrato.<br /> <br /> ===8. REVISIONES DE SEGURIDAD===<br /> <br /> ;(a) Derecho de revisión : El cliente tiene el derecho mandar revisar el software para buscar fallas de seguridad, esto a sus expesas y en cualquier momento dentro de los 60 dias despues de la entrega. El desarrollador acepta proveer apoyo rasonable al equipo de revisión proveyendo el codigo fuente y acceso a los ambientes de pruebas.<br /> <br /> ;(b) Covertura de la revisión : Las revisiones de seguridad deben cubrir todos los aspectos de el software entregado, incluyendo código a la medida, componentes, productos y configuración de sistema.<br /> <br /> ;(c) Alcance de la revisión : Al menos, la revisión debe cubrir todos los requerimientos de seguridad y debería buscar otras vulnerabilidades comunes. La revisión puede incluir una combinación de busqueda automatizada de vulnerabilidades, pruebas de intrusión, análisis estático de código fuente y revisión de código por expertos.<br /> <br /> ;(d) Problemas encontrados : Los problemas de seguridad descubiertos serán reportados a el cliente y proveedor por igual. A todos los problemas se les dará seguimiento y serán reparados como se especifique en la sección de seguimiento de problemas de seguridad de este anexo.<br /> <br /> ===9. ADMINISTRACIÓN DE PROBLEMAS DE SEGURIDAD===<br /> <br /> ;(a) Identificación : El proveedor dara seguimiento a todos los problemas de seguridad descubiertos en todo el ciclo de desarrollo, ya sea un problema en los requerimientos, diseño, implementación, pruebas, publicación u operación. El riesgo asociado con cada problema de seguridad será evaluado, documentado y reportado a el cliente tan pronto como sea posible.<br /> <br /> ;(b) Protección : El proveedor protegerá apropiadamente la información relacionada a problemas de seguridad y la documentación relacionada a ellos, esto, para ayudar a disminuir la probabilidad de las vulnerabilidades en el software operacioneal del cliente sean expuestas.<br /> <br /> ;(c) Reparación : Los problemas de seguridad que sean indentificados antes de la entrega deben ser reparados por el proveedor. Los problemas de seguridad descubiertos despues de la entrega deben ser manejados en la misma manera que otros problemas funcionales según lo especificado en este contrato.<br /> <br /> ===10. CERTEZA===<br /> <br /> ;(a) Certeza : El proveedor proveera un &quot;paquete de certificación&quot; consistente en la documentación de seguridad creada a traves del proceso de desarrollo. El paquete deberá establecer que los requerimientos de seguridad, diseño, implementación y resultados de pruebas fueron completados apropiadamente y todos los problemas de seguridad fueron resueltos apropiadamente.<br /> <br /> ;(b) Auto-Certificación : El aquitecto de seguridad certificará que el software cumple con los requerimientos de seguridad, que todas las actividades de seguridad se realizaron, y que todos los problemas de seguridad identificados han sido documentados y resueltos. Cualquier excepción a el estado de la certificacion debe estar totalmente documentada al momento de la entrega.<br /> <br /> ;(c) No código malicioso : El proveedor garantize que el sofware no debe contener ningun código que no se alinee a algun requerimiento del software y debilite la seguridad de la aplicación, incluyendo viruses, gusanos, bombas de tiempo, puertas traseras, caballos de troya, huevos de pascua y cualquier otra forma de código malicioso.<br /> <br /> ===11. CONCENTIMIENTO Y MANTENIMIENTO DE LA SEGURIDAD===<br /> <br /> ;(a) Consentimiento : El software no debe ser considerado como aceptado hasta que el paquete de certificación este completo y todos los problemas de seguridad han sido resueltos.<br /> <br /> ;(b) Investigación de problemas de seguridad : Despues del concentimiento, si se sospecha (razonablemente) o descubren problemas de seguridad, el proveedor deberá asisitir al cliente en realizar una investigación para determinar la naturaleza del problema. El problema debe ser considerado &quot;nuevo&quot; si no es cubierto por los requerientos de seguridad y esta fuera de el alcance (razonable) de las pruebas de seguridad.<br /> <br /> ;(c) Problemas de seguridad nuevos : El proveedor y el cliente consientes en medir el alcance y esfuerzo requerido para resolver problemas de seguridad nuevos, y negociad de buena fe para alcanzar un acuerdo y realizar el trabajor requerido para solucionarlos.<br /> <br /> ;(d) Otros problemas de seguridad : El proveedor debe usar todos los esfuersos comercialmente rasonables consistentes con practicas de desarrollo comunes en la industria, tomando en cuenta la severidad de el riesgo, para resolver todos los problemas de seguridad considerados nuevos tan pronto como sea posible.<br /> <br /> [[Category:OWASP Legal Project]]<br /> <br /> __NOTOC__</div>

Jorge Correa https://wiki.owasp.org/index.php?title=Anexo_para_Contrato_de_Software_Seguro_de_OWASP&diff=79720 2010-03-12T13:39:09Z

<p>Jorge Correa: </p> <hr /> <div>'''ANEXO DE CONTRATO PARA DESAROLLO DE SOFTWARE SEGURO'''<br /> <br /> ADVERTENCIA: ESTE DOCUMENTO DEBE SER CONSIDERADO COMO UNA GUÍA SOLAMENTE.<br /> OWASP RECOMIENDA VEHEMENTEMENTE QUE CONSULTE UN ABOGADO CALIFICADO<br /> PARA AYUDARLE A NEGOCIAR UN CONTRATO DE SOFTWARE<br /> <br /> == Introducción ==<br /> <br /> Este anexo de contrato pretende ayudar a los proveedores de software y sus clientes a negociar y capturar importantes términos y condiciones contractuales relacionadas a la seguridad en el Software a ser desarrollado o entregado. La razon para este proyecto es que la mayoría de los contratos no mencionan estos temas, y las partes frecuentamente tienen puntos de vista dramaticamente diferentes a lo que en ralidad fue acordado. Creemos que articular claramente estos términos es la mejor manera de asegurarse que ambas partes pueden hacer desiciones informadas sobre como proceder. <br /> <br /> &quot;La seguridad del software comercial mejorará cuando el mercado demande mejor seguridad.<br /> Al menos, cada petición para propuestas de software debería pedir a los vendedores <br /> detallar como van ellos a probar sus productos para encotrar vulnerabilidades de<br /> seguridad. Este paso empezará convenciendo a los vendedores de software empaquetado<br /> y proveedores externos que las compañias valoran la seguridad.&quot;<br /> <br /> -- John Pescatore, Director de investiagacion con Gartner&lt;br&gt; <br /> <br /> Pedimos a los clientes y proveedores que usen este documento como un marco para discutir<br /> espectativas y negociar responsabilidades. Este anexo se creó para ser añadido a un<br /> contrato de desarrollo de software. Estos términos son negociables, significa que ellos<br /> pueden y deben ser discutidos por el cliente y el proveedor.<br /> <br /> == SOBRE EL PROYECTO ==<br /> <br /> Este documento fue creado por la fundación OWASP (Open Web Application Security Project por sus siglas en Inglés), una organización sin animo de lucro con el objetivo de crear herramientas y documentación, gratuita y abierta para asegurar software. Para facilitar su uso en contratación privada, este documento es de dominio publico. Puede encontrar detalles adicionales sobre este proyecto en http://www.owasp.com/index.php/OWASP_Legal_Project. Son Bienvenidos comentarios de ambos, productores y consumidores de software, asi como de la comunidad legal. <br /> <br /> OWASP reconoce gratamente la contribución especial de [http://www.aspectsecurity.com Aspect Security] por su rol en la investigación y preparación de este documento.<br /> <br /> ==OBJECIONES==<br /> <br /> Las siguientes páginas cubren algunas objeciones que escuchamos frecuentemente sobre usar este lenguaje en contratos de desarrollo de software:<br /> <br /> ===PERO NO TODOS LOS TÉRMINOS SON CORRECTOS PARA NOSOTROS…===<br /> <br /> Este documento debe ser considerado un punto de inicio para su contrato. Puede que no le gusten todas las actividades, o puede querer proponer mas. Puede querer asignar responsabilidades de manera diferente. Este document no pretende capturar exactamente las necesidades de todos los clientes y proveedores de software. Pretende proveer un marco para discutir temas clave, importantes para asegurarse que el software se cree seguro. Despues de que tengan una discusión sobre seguridad y alcancen un acuerdo. Puede ajustar el convenio para que concuerde con el contrato.<br /> <br /> ===PERO, ¿QUIEN DEBE PAGAR POR ESTAS ACTIVIDADES?…===<br /> <br /> Este contrato no es sobre poner mas peso al desarollo de software. La pregunta no es sobre si hay costos asociados con seguridad (por supuesto que hay). Sino, la pregunta correcta es que actividades deberían hacerse por ambas partes para minimizar costos, y cuando deberían ocurrir.<br /> <br /> Este anexo no menciona (intensionalmente) sobre el detalle de quien debería pagar por la actividades descritas. Mientras muchas de estas actividades deben estar pasando ya, y son esperadas por muchos clientes, ellas no estan practicadas regularmente en la industria del software. La cuestion de quien paga (y cuando) debe ser parte de la negociación.<br /> <br /> Calcular el costo de la seguridad es muy difícil. Auque hay costos asociados con realizar actividades de seguridad, hay también costos importantes asociados con ignorar estas actividades. Estamos convencidos el mejor costo-beneficio para desarrollar software es reducir la probabilidad de que fallas de seguridad sean introducidas y minimzar el tiempo entre introducir una falla y arreglarla.<br /> <br /> Una distición importante a hacer cuando calculamos costos es entre construir mecanismos de seguridad y las actividades para asegurarse que esos mecanismos sean correctos y efectivos. Intentar agregar mecanismoa al final de el ciclo de desarrollo puede causar serios problemas de diseño e incrementará el costo dramáticamente. Este convenio promieve decisiones sobre mecanismos para minimizar estos costos. Similarmente, esperas hasta justo antes de la publicación para hacer actividades de aseguramiento, tales como revisión de código y pruebas de intrudión, tambien incrementaría los costos dramaticamente. Creemos que el mejor costo-beneficio para ganar certeza es poner un nivel constante de esfuerzo en el aseguramiento a través del ciclo de desarrollo.<br /> <br /> ===PERO EL NIVEL DE RIGOR ESTA INCORRECTO….===<br /> <br /> Este convenio asume que el software que esta siendo desarrollado es rasonablemente importante para una empresa grande o agencia de gobierno. Hemos seleccionado un &quot;nivel de rigor&quot; para el convenio que es alcanzable por la mayoria de las organizaciones proveedoras de software, e identificaría y manejaría los riesgos más comunes.<br /> <br /> Sin embargo, para el software que va a ser usado en aplicaciones críticas, como aplicaciones médicas, financieras o relacionadas con el ejército. Puede querer incrementar el nivel de rigor. Puede querer agregar revisiones, documentación y actividades adicionales de prueba. Puede querer mejorar el proceso de encontrar, diagnosticar y remediar vulnerabilidades. Para aplicaciones menos sensibles, puede desear reducir o remover actividades.<br /> <br /> ===PERO NOSOTROS NO PODEMOS ACEPTAR TANTO RIESGO…===<br /> Este convenio pretende facilitar la discusión sobre quien tomaría el riesgo por las vulnerabilidades de seguridad en el software. Por un lado del espectro, el cliente podria tomar todo el riesgo y el proveedor podria entregar código con muchas vulnerabilidades. Por el otro extremo, el proveedor podría tomar todo el riesgo y asumir la responsabilidad de entregar código perfecto. Ambos extremos son irrealizables.<br /> <br /> Actualmente, en este convenio, el proveedor toma el riesgo por problemas que sean descubiertos en los requerimientos o deben ser cubiertos por esfuerzos razonables en pruebas. Pero la remediación de &quot;nuevos&quot; problemas de seguridad tendría que ser pagado por el cliente. Creemos que este es un equilibrio funcional, ya que limita el riesgo adquirido por el proveedor y promueve obtener requerimientos de seguridad por anticipado. Pero hay muchas otras posibles soluciones a este problema. Por favor, dejenos saber si tiene sugerencias alternas, podriamos incluirlas en versiones futuras de este documento.<br /> <br /> Note que la discusión aqui solo cubre el riesgo asociado con arreglar las vulnerabilidades de seguridad en el código, y no incluye los costos asociados con recuperarse de incidentes de seguridad relacionados con explotar cualquiera de esas vulnerabilidades. Estamos interesados en mejores prácticas en esta area.<br /> <br /> ===PERO COMO PODEMOS ASEGURAR CÓDIGO DE TERCEROS…===<br /> <br /> Casi todos los proyectos de sofware tienen una cantidad importante de código de terceros como librarieas, frameworks y productos. Desde la perspectiva de seguridad, este código es tan importante como el código desarrollado a la medida para su proyecto.<br /> Creemos que la responsabilidad de asegurar la seguridad de este código es llevada mejor por el proveedor, aunque ellos podrían no tener toda la capacidad para garantizar la seguridad por ellos mismos. Sin embargo, La seguridad puede ser parte de el la desición de &quot;construir o comprar&quot;, y esta parece ser la mejor manera de promoverla.<br /> <br /> El proveedor, por supuesto, tiene la opción de pasar la responsabilidad a el proveedor del software de terceros. El desarrolador puede tambien analizar el código de terceros por él mismo o contratar expertos en seguridad para analizarlo por él.<br /> <br /> ===PERO PORQUE DEBO PASAR POR TODO ESTE PROBLEMA…===<br /> <br /> En última instancia, creemos que no hay alternativa para hacer de la seguridad una parte de el proceso de contratación de software. Actualmente, creemos que hay serios malentendidos sobre la seguridad del código que esta siendo desarrollado bajo muchos contratos de desarrollo de software. Esto puede solamente llevar a una cara litigación y a desiciones hechas por individuos con poca experiencia y entendimiento sobre software. Lea el [[Secure software contracting hypothetical case study | Caso de estudio hipotético sobre contratación de software seguro]] para una discusión completa de este problema.<br /> <br /> Hay muchos beneficios al trabajar con este convenio. El principal es que pondrá claras las expectativas entre las partes involucradas. En algunos casos ayudará a evitar demandas cuando problemas de seguridad difíciles aparecen en el software. Tambien, estan son las mismas actividades requeridas por muchas razónes legales y de conformidad con estándares/leyes.<br /> <br /> ===PERO ES MUY DIFÍCIL PRODUCIR TODA ESTA DOCUMENTACIÓN…===<br /> <br /> OWASP no promueve la documentacion por la simpre documentacion. Este convenio esta enfocado en promover la calidad, no la cantidad. Creemos que puede ser posible (en algunos proyectos) cumplir con este contrato con una pequeña evaluacion de riesgo, algunas páginas de requerimientos, un pequeño documento de diseño de seguridad, un plan de pruebas, y algunos resultados de pruebas.<br /> <br /> El objetivo de esta documentación es simplemente asegurar, en cada etapa del desarrollo de software, que se ha puesto la atención apropiada en la seguridad. Un beneficio adiciona es que esta documentacion puede ser recolectada en conjunto para formar un &quot;paquete de certificación&quot; que básicamente esbose el argumento de porque deberiamos confiar que el software hará lo que dice.<br /> <br /> ==ANEXO DE CONTRATO==<br /> <br /> ===1. INTRODUCCIÓN===<br /> <br /> Esta anexo esta hecho para _____________________ (&quot;convenio&quot;) entre el Cliente y el proveedor. Tanto el Cliente como el proveedor acuerdan maximisar la seguridad del software de acuerdo a los siguientes términos.<br /> <br /> <br /> ===2. FILOSOFÍA===<br /> <br /> Esta anexo pretende aclarar los derechos y obligaciones relacionados a seguridad de todas las partes en una relacion de desarrollo de software. Al mayor nivel, las partes acuerdan que:<br /> <br /> ;(a) Las desiciones de seguridad estarán basadas en el riesgo : Las desciciones sobre la seguridad seran tomadas en conunto por el cliente y el proveedor basandose en un firme entendimiento de el riesgo involucrado. <br /> <br /> ;(b) Las actividades de seguridad estarán balanceadas : El esfurzo de seguridad será distribuido equitativamente a través de todo el ciclo de desarollo de software.<br /> <br /> ;(c) Las actividades de seguridad estarán integradas : Todas las actividades y documentación discutidas aqui pueden y deben ser integradas dentro del ciclo de desarrollo de software del proveedor y no mantenerse separadas de el resto del proyecto. Nada en este anexo implica algún processo de desarrollo de software en particular.<br /> <br /> ;(d) Se esperan vulnerabilidades : Todo software contiene defectos, y algunos de estos crearan problemas de seguridad. Ambos, cliente y proveedor se esforzará para identificar las vulnerabilidades tan pronto como sea posible en el ciclo de desarrollo.<br /> <br /> ;(e) La información sobre seguridad será comunicada por completo : Toda la información relevante para la seguridad se compartirá entre el cliente y el proveedor inmediatamente y completamente.<br /> <br /> ;(f) Se requerirá solo documentacion de seguridad necesaria : La documentación de seguridad no necesita ser demasiado amplia para describir claramente el diseño de seguridad, análisis de riesgo y problemas.<br /> <br /> ===3. ACTIVIDADES EN EL CICLO DE DESARROLLO===<br /> <br /> ;(a) Entendimiento del Riesgo : El proveedor y el cliente acuerdan trabajar juntos para entender y documentar los riesgos que enfrenta la aplicacion. Este esfuerzo debe identificar los riesgos clave para los activos y funciones importantes que provee la aplicación. Cada uno de los temas listados en la sección de requerimientos debe ser considerado.<br /> <br /> ;(b) Requerimientos : Basado en los riesgos, El proveedor y cliente acuerda trabajar juntos para crear requerimientos de seguridad detallados como parte de la especificacion de el software a ser desarrollado. Cada uno de los temas listados en la sección de requerimientos de este anexo deben ser discutidos y evaluados por ambos, cliente y proveedor. Estos requerimientos pueden ser satisfechos por software creado a la medida, software de terceros, o la plataforma. <br /> <br /> ;(c) Diseño : el desarollador acuerda proveer documentation que explique claramente el diseño para adquirir cada uno de los requerimientos de seguridad. En muchos de los casos, esta documentacion describirá los mecanismos de seguridad, donde se incluiran dentro de la arquitectura, y todos los patrones de diseño relevantes para asegurar su uso adecuado. El diseño debe especificar claramente si tales mecanismos vienen de software a la medida, software de terceros o de la plataforma.<br /> <br /> ;(d) Implementación : El proveedor acuerda entregar y seguir un conjunto de lineamientos de codificación segura. Estos lineamientos indicarán como sele de debe dar formato, estructurar y comentar el código fuente. Todo código relacionado a seguridad debe ser comentado profundamente. Guías sobre como evitar vulnerabilidades se seguridad comunes debe ser incluida. Tambien, todo el código debe ser revisado por al menos otro desarollador basandose en los requerimientos de seguridad y los lineamientos de codificación antes de ser conciderado listo para pruebas unitarias.<br /> <br /> ;(e) Pruebas y análisis de seguridad : El proveedor acuerda entregar y seguir un plan de pruebas de seguridad que defina como se realizarán las pruebas o bien establecer como cada uno de los requerimientos de seguridad va a ser complido. El nivel de rigor de esta actividad debe ser considerado y detallado en un plan. El proveedor ejecutará el plan de prueba y proveera los resultados a el cliente.<br /> <br /> ;(f) Publicación segura : El proveedor acuerda entregar lineamientos de configuración segura que describan completamente todas las opciones de configuracion relacionadas con seguridad y sus implicaciones para la seguridad del software en su conjunto. Los lineamientos deben incluir una descripción completa de las dependencias en la plataforma y como deben ser configuradas de manera segura, incluidas las del sistema operativo, servidor Web y servidor de aplicacion. La configuracion predeterminada del software debe ser segura.<br /> <br /> ===4. ÁREAS CON REQUERIMIENTOS DE SEGURIDAD===<br /> <br /> Los siguientes temas/áreas deben ser considerados durante las actividades de entendimiento de riesgo y definición de requerimientos. Este esfuerzo debe producir un conjunto de requerimientos ajustados, especificos y probables. Ambos, proveedor y cliente deben ser involucrados en este proceso y deben ponerse de acuerdo sobre el conjunto final de requerimientos.<br /> <br /> ;(a) Validación de entradas y condificación : Los requerimientos deben especificar las reglas para canonicalización, validación y codificación de cada dato de entrada a la aplicación, ya sea de usuarios, sistemas de archivos, bases de datos o sistemas externos. La regla predeterminada debe ser que todas las entradas sean validadas a menos que cumplan con una especificacion detallada de que esta permitido. Además, los requerimientos deben especificar las acciones a tomar cuando se reciven entradas no válidas. Especificamente, la aplicación no debe ser susceptible a inyecciones, desbordamientos, manipulación y otros ataques con entradas de usuario corruptas.<br /> <br /> ;(b) Autentificación y manejo de sessiones : Los requerimientos deben especificar como se protegeran las credenciales para autentificación y los identificadores de sesión a través del ciclo de desarrollo de software. Los requerimientos para todas las funciones relacionadas deben ser agregadas incluyendo recuperar contraseñas, cambio de contraseñas, recordar contraseñas, desconexión y conexión multiple.<br /> <br /> ;(c) Control de Acceso : Los requerimientos deben incluir una descripcion detallada de todos los roles (grupos, privilegios, autorizaciones) usadas en la aplicación. Los requerimientos deben indicar todos los activos y funciones que provee la aplicacion. Los requerimientos deben especificar detallada y exactamente los derechos de acceso para cualquier activo y función de cada rol. Se sugiere utilizar un formato de matriz de control de acceso para documentar estas reglas.<br /> <br /> ;(d) Manejo de Errores : Los requerimientos deben detallar como se van a manejar los errores que ocurran dentro del procesamiento. Algunas aplicaciones deberían hacer lo mejor posible en caso de un error, mientras que otras deberían terminar su procesamiento inmediatamente.<br /> <br /> ;(e) Historial : Los requerimientos deben especificar que eventos son relevantes para la seguridad y necesitan ser registrados, como ataques detectados, intentos de conexión fallidos e intentos de exeder la autorización. Los requerimientos deben especificar tambien que information registrar con cada evento, incluyendo hora y fecha, descripción del evento, detalles de aplicación, y otra información útil en esfuerzos forences.<br /> <br /> ;(f) Conexiones a sistemas externos : Los requerimientos deben especifica como la autentificación y cifrado será manejado para todos los systemas externos, tales como bases de datos, directorios y servicios Web. Todas las credenciales requeridas para la comunicación con sistemas externos deben almacenarce cifradas y fuera de el código dentro de archivos de configuración. <br /> <br /> ;(g) Cifrado : Los requerimientos deben especificar que datos deben ser cifrados, como serán cifrados y como todos los certificados y otras credenciales deben ser manejadas. Las aplicaciones deben usar algoritmos estándar implementados en una librerias de cifrado que hayan sido usadas y probadas ampliamente.<br /> <br /> ;(h) Disponibilidad : Los requerimientos deben especificar como protegerse de ataques de negación de servicio. Todos los posibles ataques en la aplicacion deben ser considerados, incluyendo bloqueos de auntentificación, agotamiento de conexiones y otros ataques de agotamiento de recursos.<br /> <br /> ;(i) Configuración segura : Los requerimientos deben especificar que los valores predeterminados para todas las configuraciones relacionadas a seguridad deben ser seguras. Para propósitos de auditoría, el software deberia ser capás de producir un reporte sencillo de leer que muestre los detalles de todas las configuraciones relacionadas con seguridad.<br /> <br /> ;(j) Vulnerabilidades especificas : Los requerimientos deben incluir un conjunto de vulnerabilidades especificas que no deben estar presentes en el software. A menos que sea especificado de otra manera, el software no debe incluir ninguna de las fallas descritas en el la &quot;Lista de OWASP sobre las 10 vulnerabilidades mas críticas en aplicaciones Web&quot;.<br /> <br /> ===5. PERSONAL Y ORGANIZACIÓN===<br /> <br /> ;(a) Arquitecto en seguridad : El desarollador asignará la responsabilidad por la seguridad a un solo recurso técnico experimentado, para ser conocido como el arquitecto de seguridad del proyecto. El arquitecto de seguridad certificará la seguridad de cada entregable.<br /> <br /> ;(b) Entrenamiento en Seguridad : el proveedor será responsable de verificar que todos los miembros del equipo de desarrollo han sido entrenados en tecnicas de programación segura.<br /> <br /> ;(c) Desarrolladores dignos de confianza : El proveedor acuerda realizar las investigaciones de antecendentes apropiadas a todos los miembros del equipo de desarrollo.<br /> <br /> ===6. AMBIENTE DE DESARROLLO===<br /> <br /> ;(a) Codificación segura : El proveedor debe mencionar que herramientas se usarán en el ambiente de desarrollo de software para promover la codificación segura.<br /> <br /> ;(b) Adminstración de configuración : El proveedor debe usar un sistema de control de versiones que autentifique y registre el miembro del equipo asociado con todos los cambios en el código base, todos los archivos de configuración y compilación.<br /> <br /> ;(c) Distribución : El proveedor debe usar un proceso de compilación que construya confiablemente un archivo de distribución completo desde el código fuente. Este proceso debe incluir un método para verificar la integridad de el software entregado al cliente.<br /> <br /> ===7. LIBRERIAS, MARCOS DE DESARROLLO Y PRODUCTOS===<br /> <br /> ;(a) Apertura : El proveedor debe mencionar todas los aplicaciones de terceros usadas en el software, incluyendo todas las librerias, marcos de desarrollo, componentes y otros productos, ya sean comerciales, gratuitos, de código abierto o código cerrado.<br /> <br /> ;(b) Evaluación : El proveedor debe hacer esfuerzos rasonables para asegurar que el sofware de terceros cumple con todos los términos de este contrato y es tan seguro como el código a la medida desarrollado bajo este contrato.<br /> <br /> ===8. REVISIONES DE SEGURIDAD===<br /> <br /> ;(a) Derecho de revisión : El cliente tiene el derecho mandar revisar el software para buscar fallas de seguridad, esto a sus expesas y en cualquier momento dentro de los 60 dias despues de la entrega. El desarrollador acepta proveer apoyo rasonable al equipo de revisión proveyendo el codigo fuente y acceso a los ambientes de pruebas.<br /> <br /> ;(b) Covertura de la revisión : Las revisiones de seguridad deben cubrir todos los aspectos de el software entregado, incluyendo código a la medida, componentes, productos y configuración de sistema.<br /> <br /> ;(c) Alcance de la revisión : Al menos, la revisión debe cubrir todos los requerimientos de seguridad y debería buscar otras vulnerabilidades comunes. La revisión puede incluir una combinación de busqueda automatizada de vulnerabilidades, pruebas de intrusión, análisis estático de código fuente y revisión de código por expertos.<br /> <br /> ;(d) Problemas encontrados : Los problemas de seguridad descubiertos serán reportados a el cliente y proveedor por igual. A todos los problemas se les dará seguimiento y serán reparados como se especifique en la sección de seguimiento de problemas de seguridad de este anexo.<br /> <br /> ===9. ADMINISTRACIÓN DE PROBLEMAS DE SEGURIDAD===<br /> <br /> ;(a) Identificación : El proveedor dara seguimiento a todos los problemas de seguridad descubiertos en todo el ciclo de desarrollo, ya sea un problema en los requerimientos, diseño, implementación, pruebas, publicación u operación. El riesgo asociado con cada problema de seguridad será evaluado, documentado y reportado a el cliente tan pronto como sea posible.<br /> <br /> ;(b) Protección : El proveedor protegerá apropiadamente la información relacionada a problemas de seguridad y la documentación relacionada a ellos, esto, para ayudar a disminuir la probabilidad de las vulnerabilidades en el software operacioneal del cliente sean expuestas.<br /> <br /> ;(c) Reparación : Los problemas de seguridad que sean indentificados antes de la entrega deben ser reparados por el proveedor. Los problemas de seguridad descubiertos despues de la entrega deben ser manejados en la misma manera que otros problemas funcionales según lo especificado en este contrato.<br /> <br /> ===10. CERTEZA===<br /> <br /> ;(a) Certeza : El proveedor proveera un &quot;paquete de certificación&quot; consistente en la documentación de seguridad creada a traves del proceso de desarrollo. El paquete deberá establecer que los requerimientos de seguridad, diseño, implementación y resultados de pruebas fueron completados apropiadamente y todos los problemas de seguridad fueron resueltos apropiadamente.<br /> <br /> ;(b) Auto-Certificación : El aquitecto de seguridad certificará que el software cumple con los requerimientos de seguridad, que todas las actividades de seguridad se realizaron, y que todos los problemas de seguridad identificados han sido documentados y resueltos. Cualquier excepción a el estado de la certificacion debe estar totalmente documentada al momento de la entrega.<br /> <br /> ;(c) No código malicioso : El proveedor garantize que el sofware no debe contener ningun código que no se alinee a algun requerimiento del software y debilite la seguridad de la aplicación, incluyendo viruses, gusanos, bombas de tiempo, puertas traseras, caballos de troya, huevos de pascua y cualquier otra forma de código malicioso.<br /> <br /> ===11. CONCENTIMIENTO Y MANTENIMIENTO DE LA SEGURIDAD===<br /> <br /> ;(a) Consentimiento : El software no debe ser considerado como aceptado hasta que el paquete de certificación este completo y todos los problemas de seguridad han sido resueltos.<br /> <br /> ;(b) Investigación de problemas de seguridad : Despues del concentimiento, si se sospecha (razonablemente) o descubren problemas de seguridad, el proveedor deberá asisitir al cliente en realizar una investigación para determinar la naturaleza del problema. El problema debe ser considerado &quot;nuevo&quot; si no es cubierto por los requerientos de seguridad y esta fuera de el alcance (razonable) de las pruebas de seguridad.<br /> <br /> ;(c) Problemas de seguridad nuevos : El proveedor y el cliente consientes en medir el alcance y esfuerzo requerido para resolver problemas de seguridad nuevos, y negociad de buena fe para alcanzar un acuerdo y realizar el trabajor requerido para solucionarlos.<br /> <br /> ;(d) Otros problemas de seguridad : El proveedor debe usar todos los esfuersos comercialmente rasonables consistentes con practicas de desarrollo comunes en la industria, tomando en cuenta la severidad de el riesgo, para resolver todos los problemas de seguridad considerados nuevos tan pronto como sea posible.<br /> <br /> [[Category:OWASP Legal Project]]<br /> <br /> __NOTOC__</div>

Jorge Correa https://wiki.owasp.org/index.php?title=Anexo_para_Contrato_de_Software_Seguro_de_OWASP&diff=79719 2010-03-12T13:37:51Z

<p>Jorge Correa: </p> <hr /> <div>'''ANEXO DE CONTRATO PARA DESAROLLO DE SOFTWARE SEGURO'''<br /> <br /> ADVERTENCIA: ESTE DOCUMENTO DEBE SER CONSIDERADO COMO UNA GUÍA SOLAMENTE.<br /> OWASP RECOMIENDA VEHEMENTEMENTE QUE CONSULTE UN ABOGADO CALIFICADO<br /> PARA AYUDARLE A NEGOCIAR UN CONTRATO DE SOFTWARE<br /> <br /> == Introducción ==<br /> <br /> Este anexo de contrato pretende ayudar a los proveedores de software y sus clientes a negociar y capturar importantes términos y condiciones contractuales relacionadas a la seguridad en el Software a ser desarrollado o entregado. La razon para este proyecto es que la mayoría de los contratos no mencionan estos temas, y las partes frecuentamente tienen puntos de vista dramaticamente diferentes a lo que en ralidad fue acordado. Creemos que articular claramente estos términos es la mejor manera de asegurarse que ambas partes pueden hacer desiciones informadas sobre como proceder. <br /> <br /> &quot;La seguridad del software comercial mejorará cuando el mercado demande mejor seguridad.<br /> Al menos, cada petición para propuestas de software debería pedir a los vendedores <br /> detallar como van ellos a probar sus productos para encotrar vulnerabilidades de<br /> seguridad. Este paso empezará convenciendo a los vendedores de software empaquetado<br /> y proveedores externos que las compañias valoran la seguridad.&quot;<br /> <br /> -- John Pescatore, Director de investiagacion con Gartner&lt;br&gt; <br /> <br /> Pedimos a los clientes y proveedores que usen este documento como un marco para discutir<br /> espectativas y negociar responsabilidades. Este anexo se creó para ser añadido a un<br /> contrato de desarrollo de software. Estos términos son negociables, significa que ellos<br /> pueden y deben ser discutidos por el cliente y el proveedor.<br /> <br /> ==SOBRE EL PROYECTO==<br /> Este documento fue creado por la fundación OWASP (Open Web Application Security Project por sus siglas en Inglés), una organización caritativa sin animos de lucro con el objetivo de crear herramientas y documentación, gratuita y abierta para asegurar software. Para facilitar su uso en contratación privada, este documento es de dominio publico. Puede encontrar detalles adicionales sobre este proyecto en http://www.owasp.com/index.php/OWASP_Legal_Project. Son Bienvenidos comentarios de ambos, productores y consumidores de software, asi como de la comunidad legal.<br /> <br /> OWASP reconoce gratamente la contribución especial de [http://www.aspectsecurity.com Aspect Security] por su rol en la investigación y preparación de este documento.<br /> <br /> ==OBJECIONES==<br /> <br /> Las siguientes páginas cubren algunas objeciones que escuchamos frecuentemente sobre usar este lenguaje en contratos de desarrollo de software:<br /> <br /> ===PERO NO TODOS LOS TÉRMINOS SON CORRECTOS PARA NOSOTROS…===<br /> <br /> Este documento debe ser considerado un punto de inicio para su contrato. Puede que no le gusten todas las actividades, o puede querer proponer mas. Puede querer asignar responsabilidades de manera diferente. Este document no pretende capturar exactamente las necesidades de todos los clientes y proveedores de software. Pretende proveer un marco para discutir temas clave, importantes para asegurarse que el software se cree seguro. Despues de que tengan una discusión sobre seguridad y alcancen un acuerdo. Puede ajustar el convenio para que concuerde con el contrato.<br /> <br /> ===PERO, ¿QUIEN DEBE PAGAR POR ESTAS ACTIVIDADES?…===<br /> <br /> Este contrato no es sobre poner mas peso al desarollo de software. La pregunta no es sobre si hay costos asociados con seguridad (por supuesto que hay). Sino, la pregunta correcta es que actividades deberían hacerse por ambas partes para minimizar costos, y cuando deberían ocurrir.<br /> <br /> Este anexo no menciona (intensionalmente) sobre el detalle de quien debería pagar por la actividades descritas. Mientras muchas de estas actividades deben estar pasando ya, y son esperadas por muchos clientes, ellas no estan practicadas regularmente en la industria del software. La cuestion de quien paga (y cuando) debe ser parte de la negociación.<br /> <br /> Calcular el costo de la seguridad es muy difícil. Auque hay costos asociados con realizar actividades de seguridad, hay también costos importantes asociados con ignorar estas actividades. Estamos convencidos el mejor costo-beneficio para desarrollar software es reducir la probabilidad de que fallas de seguridad sean introducidas y minimzar el tiempo entre introducir una falla y arreglarla.<br /> <br /> Una distición importante a hacer cuando calculamos costos es entre construir mecanismos de seguridad y las actividades para asegurarse que esos mecanismos sean correctos y efectivos. Intentar agregar mecanismoa al final de el ciclo de desarrollo puede causar serios problemas de diseño e incrementará el costo dramáticamente. Este convenio promieve decisiones sobre mecanismos para minimizar estos costos. Similarmente, esperas hasta justo antes de la publicación para hacer actividades de aseguramiento, tales como revisión de código y pruebas de intrudión, tambien incrementaría los costos dramaticamente. Creemos que el mejor costo-beneficio para ganar certeza es poner un nivel constante de esfuerzo en el aseguramiento a través del ciclo de desarrollo.<br /> <br /> ===PERO EL NIVEL DE RIGOR ESTA INCORRECTO….===<br /> <br /> Este convenio asume que el software que esta siendo desarrollado es rasonablemente importante para una empresa grande o agencia de gobierno. Hemos seleccionado un &quot;nivel de rigor&quot; para el convenio que es alcanzable por la mayoria de las organizaciones proveedoras de software, e identificaría y manejaría los riesgos más comunes.<br /> <br /> Sin embargo, para el software que va a ser usado en aplicaciones críticas, como aplicaciones médicas, financieras o relacionadas con el ejército. Puede querer incrementar el nivel de rigor. Puede querer agregar revisiones, documentación y actividades adicionales de prueba. Puede querer mejorar el proceso de encontrar, diagnosticar y remediar vulnerabilidades. Para aplicaciones menos sensibles, puede desear reducir o remover actividades.<br /> <br /> ===PERO NOSOTROS NO PODEMOS ACEPTAR TANTO RIESGO…===<br /> Este convenio pretende facilitar la discusión sobre quien tomaría el riesgo por las vulnerabilidades de seguridad en el software. Por un lado del espectro, el cliente podria tomar todo el riesgo y el proveedor podria entregar código con muchas vulnerabilidades. Por el otro extremo, el proveedor podría tomar todo el riesgo y asumir la responsabilidad de entregar código perfecto. Ambos extremos son irrealizables.<br /> <br /> Actualmente, en este convenio, el proveedor toma el riesgo por problemas que sean descubiertos en los requerimientos o deben ser cubiertos por esfuerzos razonables en pruebas. Pero la remediación de &quot;nuevos&quot; problemas de seguridad tendría que ser pagado por el cliente. Creemos que este es un equilibrio funcional, ya que limita el riesgo adquirido por el proveedor y promueve obtener requerimientos de seguridad por anticipado. Pero hay muchas otras posibles soluciones a este problema. Por favor, dejenos saber si tiene sugerencias alternas, podriamos incluirlas en versiones futuras de este documento.<br /> <br /> Note que la discusión aqui solo cubre el riesgo asociado con arreglar las vulnerabilidades de seguridad en el código, y no incluye los costos asociados con recuperarse de incidentes de seguridad relacionados con explotar cualquiera de esas vulnerabilidades. Estamos interesados en mejores prácticas en esta area.<br /> <br /> ===PERO COMO PODEMOS ASEGURAR CÓDIGO DE TERCEROS…===<br /> <br /> Casi todos los proyectos de sofware tienen una cantidad importante de código de terceros como librarieas, frameworks y productos. Desde la perspectiva de seguridad, este código es tan importante como el código desarrollado a la medida para su proyecto.<br /> Creemos que la responsabilidad de asegurar la seguridad de este código es llevada mejor por el proveedor, aunque ellos podrían no tener toda la capacidad para garantizar la seguridad por ellos mismos. Sin embargo, La seguridad puede ser parte de el la desición de &quot;construir o comprar&quot;, y esta parece ser la mejor manera de promoverla.<br /> <br /> El proveedor, por supuesto, tiene la opción de pasar la responsabilidad a el proveedor del software de terceros. El desarrolador puede tambien analizar el código de terceros por él mismo o contratar expertos en seguridad para analizarlo por él.<br /> <br /> ===PERO PORQUE DEBO PASAR POR TODO ESTE PROBLEMA…===<br /> <br /> En última instancia, creemos que no hay alternativa para hacer de la seguridad una parte de el proceso de contratación de software. Actualmente, creemos que hay serios malentendidos sobre la seguridad del código que esta siendo desarrollado bajo muchos contratos de desarrollo de software. Esto puede solamente llevar a una cara litigación y a desiciones hechas por individuos con poca experiencia y entendimiento sobre software. Lea el [[Secure software contracting hypothetical case study | Caso de estudio hipotético sobre contratación de software seguro]] para una discusión completa de este problema.<br /> <br /> Hay muchos beneficios al trabajar con este convenio. El principal es que pondrá claras las expectativas entre las partes involucradas. En algunos casos ayudará a evitar demandas cuando problemas de seguridad difíciles aparecen en el software. Tambien, estan son las mismas actividades requeridas por muchas razónes legales y de conformidad con estándares/leyes.<br /> <br /> ===PERO ES MUY DIFÍCIL PRODUCIR TODA ESTA DOCUMENTACIÓN…===<br /> <br /> OWASP no promueve la documentacion por la simpre documentacion. Este convenio esta enfocado en promover la calidad, no la cantidad. Creemos que puede ser posible (en algunos proyectos) cumplir con este contrato con una pequeña evaluacion de riesgo, algunas páginas de requerimientos, un pequeño documento de diseño de seguridad, un plan de pruebas, y algunos resultados de pruebas.<br /> <br /> El objetivo de esta documentación es simplemente asegurar, en cada etapa del desarrollo de software, que se ha puesto la atención apropiada en la seguridad. Un beneficio adiciona es que esta documentacion puede ser recolectada en conjunto para formar un &quot;paquete de certificación&quot; que básicamente esbose el argumento de porque deberiamos confiar que el software hará lo que dice.<br /> <br /> ==ANEXO DE CONTRATO==<br /> <br /> ===1. INTRODUCCIÓN===<br /> <br /> Esta anexo esta hecho para _____________________ (&quot;convenio&quot;) entre el Cliente y el proveedor. Tanto el Cliente como el proveedor acuerdan maximisar la seguridad del software de acuerdo a los siguientes términos.<br /> <br /> <br /> ===2. FILOSOFÍA===<br /> <br /> Esta anexo pretende aclarar los derechos y obligaciones relacionados a seguridad de todas las partes en una relacion de desarrollo de software. Al mayor nivel, las partes acuerdan que:<br /> <br /> ;(a) Las desiciones de seguridad estarán basadas en el riesgo : Las desciciones sobre la seguridad seran tomadas en conunto por el cliente y el proveedor basandose en un firme entendimiento de el riesgo involucrado. <br /> <br /> ;(b) Las actividades de seguridad estarán balanceadas : El esfurzo de seguridad será distribuido equitativamente a través de todo el ciclo de desarollo de software.<br /> <br /> ;(c) Las actividades de seguridad estarán integradas : Todas las actividades y documentación discutidas aqui pueden y deben ser integradas dentro del ciclo de desarrollo de software del proveedor y no mantenerse separadas de el resto del proyecto. Nada en este anexo implica algún processo de desarrollo de software en particular.<br /> <br /> ;(d) Se esperan vulnerabilidades : Todo software contiene defectos, y algunos de estos crearan problemas de seguridad. Ambos, cliente y proveedor se esforzará para identificar las vulnerabilidades tan pronto como sea posible en el ciclo de desarrollo.<br /> <br /> ;(e) La información sobre seguridad será comunicada por completo : Toda la información relevante para la seguridad se compartirá entre el cliente y el proveedor inmediatamente y completamente.<br /> <br /> ;(f) Se requerirá solo documentacion de seguridad necesaria : La documentación de seguridad no necesita ser demasiado amplia para describir claramente el diseño de seguridad, análisis de riesgo y problemas.<br /> <br /> ===3. ACTIVIDADES EN EL CICLO DE DESARROLLO===<br /> <br /> ;(a) Entendimiento del Riesgo : El proveedor y el cliente acuerdan trabajar juntos para entender y documentar los riesgos que enfrenta la aplicacion. Este esfuerzo debe identificar los riesgos clave para los activos y funciones importantes que provee la aplicación. Cada uno de los temas listados en la sección de requerimientos debe ser considerado.<br /> <br /> ;(b) Requerimientos : Basado en los riesgos, El proveedor y cliente acuerda trabajar juntos para crear requerimientos de seguridad detallados como parte de la especificacion de el software a ser desarrollado. Cada uno de los temas listados en la sección de requerimientos de este anexo deben ser discutidos y evaluados por ambos, cliente y proveedor. Estos requerimientos pueden ser satisfechos por software creado a la medida, software de terceros, o la plataforma. <br /> <br /> ;(c) Diseño : el desarollador acuerda proveer documentation que explique claramente el diseño para adquirir cada uno de los requerimientos de seguridad. En muchos de los casos, esta documentacion describirá los mecanismos de seguridad, donde se incluiran dentro de la arquitectura, y todos los patrones de diseño relevantes para asegurar su uso adecuado. El diseño debe especificar claramente si tales mecanismos vienen de software a la medida, software de terceros o de la plataforma.<br /> <br /> ;(d) Implementación : El proveedor acuerda entregar y seguir un conjunto de lineamientos de codificación segura. Estos lineamientos indicarán como sele de debe dar formato, estructurar y comentar el código fuente. Todo código relacionado a seguridad debe ser comentado profundamente. Guías sobre como evitar vulnerabilidades se seguridad comunes debe ser incluida. Tambien, todo el código debe ser revisado por al menos otro desarollador basandose en los requerimientos de seguridad y los lineamientos de codificación antes de ser conciderado listo para pruebas unitarias.<br /> <br /> ;(e) Pruebas y análisis de seguridad : El proveedor acuerda entregar y seguir un plan de pruebas de seguridad que defina como se realizarán las pruebas o bien establecer como cada uno de los requerimientos de seguridad va a ser complido. El nivel de rigor de esta actividad debe ser considerado y detallado en un plan. El proveedor ejecutará el plan de prueba y proveera los resultados a el cliente.<br /> <br /> ;(f) Publicación segura : El proveedor acuerda entregar lineamientos de configuración segura que describan completamente todas las opciones de configuracion relacionadas con seguridad y sus implicaciones para la seguridad del software en su conjunto. Los lineamientos deben incluir una descripción completa de las dependencias en la plataforma y como deben ser configuradas de manera segura, incluidas las del sistema operativo, servidor Web y servidor de aplicacion. La configuracion predeterminada del software debe ser segura.<br /> <br /> ===4. ÁREAS CON REQUERIMIENTOS DE SEGURIDAD===<br /> <br /> Los siguientes temas/áreas deben ser considerados durante las actividades de entendimiento de riesgo y definición de requerimientos. Este esfuerzo debe producir un conjunto de requerimientos ajustados, especificos y probables. Ambos, proveedor y cliente deben ser involucrados en este proceso y deben ponerse de acuerdo sobre el conjunto final de requerimientos.<br /> <br /> ;(a) Validación de entradas y condificación : Los requerimientos deben especificar las reglas para canonicalización, validación y codificación de cada dato de entrada a la aplicación, ya sea de usuarios, sistemas de archivos, bases de datos o sistemas externos. La regla predeterminada debe ser que todas las entradas sean validadas a menos que cumplan con una especificacion detallada de que esta permitido. Además, los requerimientos deben especificar las acciones a tomar cuando se reciven entradas no válidas. Especificamente, la aplicación no debe ser susceptible a inyecciones, desbordamientos, manipulación y otros ataques con entradas de usuario corruptas.<br /> <br /> ;(b) Autentificación y manejo de sessiones : Los requerimientos deben especificar como se protegeran las credenciales para autentificación y los identificadores de sesión a través del ciclo de desarrollo de software. Los requerimientos para todas las funciones relacionadas deben ser agregadas incluyendo recuperar contraseñas, cambio de contraseñas, recordar contraseñas, desconexión y conexión multiple.<br /> <br /> ;(c) Control de Acceso : Los requerimientos deben incluir una descripcion detallada de todos los roles (grupos, privilegios, autorizaciones) usadas en la aplicación. Los requerimientos deben indicar todos los activos y funciones que provee la aplicacion. Los requerimientos deben especificar detallada y exactamente los derechos de acceso para cualquier activo y función de cada rol. Se sugiere utilizar un formato de matriz de control de acceso para documentar estas reglas.<br /> <br /> ;(d) Manejo de Errores : Los requerimientos deben detallar como se van a manejar los errores que ocurran dentro del procesamiento. Algunas aplicaciones deberían hacer lo mejor posible en caso de un error, mientras que otras deberían terminar su procesamiento inmediatamente.<br /> <br /> ;(e) Historial : Los requerimientos deben especificar que eventos son relevantes para la seguridad y necesitan ser registrados, como ataques detectados, intentos de conexión fallidos e intentos de exeder la autorización. Los requerimientos deben especificar tambien que information registrar con cada evento, incluyendo hora y fecha, descripción del evento, detalles de aplicación, y otra información útil en esfuerzos forences.<br /> <br /> ;(f) Conexiones a sistemas externos : Los requerimientos deben especifica como la autentificación y cifrado será manejado para todos los systemas externos, tales como bases de datos, directorios y servicios Web. Todas las credenciales requeridas para la comunicación con sistemas externos deben almacenarce cifradas y fuera de el código dentro de archivos de configuración. <br /> <br /> ;(g) Cifrado : Los requerimientos deben especificar que datos deben ser cifrados, como serán cifrados y como todos los certificados y otras credenciales deben ser manejadas. Las aplicaciones deben usar algoritmos estándar implementados en una librerias de cifrado que hayan sido usadas y probadas ampliamente.<br /> <br /> ;(h) Disponibilidad : Los requerimientos deben especificar como protegerse de ataques de negación de servicio. Todos los posibles ataques en la aplicacion deben ser considerados, incluyendo bloqueos de auntentificación, agotamiento de conexiones y otros ataques de agotamiento de recursos.<br /> <br /> ;(i) Configuración segura : Los requerimientos deben especificar que los valores predeterminados para todas las configuraciones relacionadas a seguridad deben ser seguras. Para propósitos de auditoría, el software deberia ser capás de producir un reporte sencillo de leer que muestre los detalles de todas las configuraciones relacionadas con seguridad.<br /> <br /> ;(j) Vulnerabilidades especificas : Los requerimientos deben incluir un conjunto de vulnerabilidades especificas que no deben estar presentes en el software. A menos que sea especificado de otra manera, el software no debe incluir ninguna de las fallas descritas en el la &quot;Lista de OWASP sobre las 10 vulnerabilidades mas críticas en aplicaciones Web&quot;.<br /> <br /> ===5. PERSONAL Y ORGANIZACIÓN===<br /> <br /> ;(a) Arquitecto en seguridad : El desarollador asignará la responsabilidad por la seguridad a un solo recurso técnico experimentado, para ser conocido como el arquitecto de seguridad del proyecto. El arquitecto de seguridad certificará la seguridad de cada entregable.<br /> <br /> ;(b) Entrenamiento en Seguridad : el proveedor será responsable de verificar que todos los miembros del equipo de desarrollo han sido entrenados en tecnicas de programación segura.<br /> <br /> ;(c) Desarrolladores dignos de confianza : El proveedor acuerda realizar las investigaciones de antecendentes apropiadas a todos los miembros del equipo de desarrollo.<br /> <br /> ===6. AMBIENTE DE DESARROLLO===<br /> <br /> ;(a) Codificación segura : El proveedor debe mencionar que herramientas se usarán en el ambiente de desarrollo de software para promover la codificación segura.<br /> <br /> ;(b) Adminstración de configuración : El proveedor debe usar un sistema de control de versiones que autentifique y registre el miembro del equipo asociado con todos los cambios en el código base, todos los archivos de configuración y compilación.<br /> <br /> ;(c) Distribución : El proveedor debe usar un proceso de compilación que construya confiablemente un archivo de distribución completo desde el código fuente. Este proceso debe incluir un método para verificar la integridad de el software entregado al cliente.<br /> <br /> ===7. LIBRERIAS, MARCOS DE DESARROLLO Y PRODUCTOS===<br /> <br /> ;(a) Apertura : El proveedor debe mencionar todas los aplicaciones de terceros usadas en el software, incluyendo todas las librerias, marcos de desarrollo, componentes y otros productos, ya sean comerciales, gratuitos, de código abierto o código cerrado.<br /> <br /> ;(b) Evaluación : El proveedor debe hacer esfuerzos rasonables para asegurar que el sofware de terceros cumple con todos los términos de este contrato y es tan seguro como el código a la medida desarrollado bajo este contrato.<br /> <br /> ===8. REVISIONES DE SEGURIDAD===<br /> <br /> ;(a) Derecho de revisión : El cliente tiene el derecho mandar revisar el software para buscar fallas de seguridad, esto a sus expesas y en cualquier momento dentro de los 60 dias despues de la entrega. El desarrollador acepta proveer apoyo rasonable al equipo de revisión proveyendo el codigo fuente y acceso a los ambientes de pruebas.<br /> <br /> ;(b) Covertura de la revisión : Las revisiones de seguridad deben cubrir todos los aspectos de el software entregado, incluyendo código a la medida, componentes, productos y configuración de sistema.<br /> <br /> ;(c) Alcance de la revisión : Al menos, la revisión debe cubrir todos los requerimientos de seguridad y debería buscar otras vulnerabilidades comunes. La revisión puede incluir una combinación de busqueda automatizada de vulnerabilidades, pruebas de intrusión, análisis estático de código fuente y revisión de código por expertos.<br /> <br /> ;(d) Problemas encontrados : Los problemas de seguridad descubiertos serán reportados a el cliente y proveedor por igual. A todos los problemas se les dará seguimiento y serán reparados como se especifique en la sección de seguimiento de problemas de seguridad de este anexo.<br /> <br /> ===9. ADMINISTRACIÓN DE PROBLEMAS DE SEGURIDAD===<br /> <br /> ;(a) Identificación : El proveedor dara seguimiento a todos los problemas de seguridad descubiertos en todo el ciclo de desarrollo, ya sea un problema en los requerimientos, diseño, implementación, pruebas, publicación u operación. El riesgo asociado con cada problema de seguridad será evaluado, documentado y reportado a el cliente tan pronto como sea posible.<br /> <br /> ;(b) Protección : El proveedor protegerá apropiadamente la información relacionada a problemas de seguridad y la documentación relacionada a ellos, esto, para ayudar a disminuir la probabilidad de las vulnerabilidades en el software operacioneal del cliente sean expuestas.<br /> <br /> ;(c) Reparación : Los problemas de seguridad que sean indentificados antes de la entrega deben ser reparados por el proveedor. Los problemas de seguridad descubiertos despues de la entrega deben ser manejados en la misma manera que otros problemas funcionales según lo especificado en este contrato.<br /> <br /> ===10. CERTEZA===<br /> <br /> ;(a) Certeza : El proveedor proveera un &quot;paquete de certificación&quot; consistente en la documentación de seguridad creada a traves del proceso de desarrollo. El paquete deberá establecer que los requerimientos de seguridad, diseño, implementación y resultados de pruebas fueron completados apropiadamente y todos los problemas de seguridad fueron resueltos apropiadamente.<br /> <br /> ;(b) Auto-Certificación : El aquitecto de seguridad certificará que el software cumple con los requerimientos de seguridad, que todas las actividades de seguridad se realizaron, y que todos los problemas de seguridad identificados han sido documentados y resueltos. Cualquier excepción a el estado de la certificacion debe estar totalmente documentada al momento de la entrega.<br /> <br /> ;(c) No código malicioso : El proveedor garantize que el sofware no debe contener ningun código que no se alinee a algun requerimiento del software y debilite la seguridad de la aplicación, incluyendo viruses, gusanos, bombas de tiempo, puertas traseras, caballos de troya, huevos de pascua y cualquier otra forma de código malicioso.<br /> <br /> ===11. CONCENTIMIENTO Y MANTENIMIENTO DE LA SEGURIDAD===<br /> <br /> ;(a) Consentimiento : El software no debe ser considerado como aceptado hasta que el paquete de certificación este completo y todos los problemas de seguridad han sido resueltos.<br /> <br /> ;(b) Investigación de problemas de seguridad : Despues del concentimiento, si se sospecha (razonablemente) o descubren problemas de seguridad, el proveedor deberá asisitir al cliente en realizar una investigación para determinar la naturaleza del problema. El problema debe ser considerado &quot;nuevo&quot; si no es cubierto por los requerientos de seguridad y esta fuera de el alcance (razonable) de las pruebas de seguridad.<br /> <br /> ;(c) Problemas de seguridad nuevos : El proveedor y el cliente consientes en medir el alcance y esfuerzo requerido para resolver problemas de seguridad nuevos, y negociad de buena fe para alcanzar un acuerdo y realizar el trabajor requerido para solucionarlos.<br /> <br /> ;(d) Otros problemas de seguridad : El proveedor debe usar todos los esfuersos comercialmente rasonables consistentes con practicas de desarrollo comunes en la industria, tomando en cuenta la severidad de el riesgo, para resolver todos los problemas de seguridad considerados nuevos tan pronto como sea posible.<br /> <br /> [[Category:OWASP Legal Project]]<br /> <br /> __NOTOC__</div>

Jorge Correa https://wiki.owasp.org/index.php?title=Anexo_para_Contrato_de_Software_Seguro_de_OWASP&diff=79717 2010-03-12T13:33:46Z

<p>Jorge Correa: /* Introducción */</p> <hr /> <div>'''ANEXO DE CONTRATO PARA DESAROLLO DE SOFTWARE SEGURO'''<br /> <br /> ADVERTENCIA: ESTE DOCUMENTO DEBE SER CONSIDERADO COMO UNA GUÍA SOLAMENTE.<br /> OWASP RECOMIENDA VEHEMENTEMENTE QUE CONSULTE UN ABOGADO CALIFICADO<br /> PARA AYUDARLE A NEGOCIAR UN CONTRATO DE SOFTWARE<br /> <br /> == Introducción ==<br /> <br /> Este anexo de contrato pretende ayudar a los proveedores de software y sus clientes a negociar y capturar importantes términos y condiciones contractuales relacionadas a la seguridad en el Software a ser desarrollado o entregado. La razon para este proyecto es que la mayoría de los contratos no mencionan estos temas, y las partes frecuentamente tienen puntos de vista dramaticamente diferentes a lo que en ralidad fue acordado. Creemos que articular claramente estos términos es la mejor manera de asegurarse que ambas partes pueden hacer desiciones informadas sobre como proceder. <br /> <br /> &quot;La seguridad del software comercial mejorará cuando el mercado demande mejor seguridad.<br /> Al menos, cada petición para propuestas de software debería pedir a los vendedores detallar como van ellos a probar <br /> sus productos para encotrar vulnerabilidades de seguridad.Este paso empezará convenciendo a los vendedores de<br /> software empaquetado y proveedores externos que las compañias valoran la seguridad.&quot;<br /> <br /> -- John Pescatore, Director de investiagacion con Gartner&lt;br&gt; <br /> <br /> Pedimos a los clientes y proveedores que usen este documento como un marco para discutir espectativas y negociar<br /> responsabilidades. Este anexo se creó para ser añadido a un contrato de desarrollo de software. Estos términos son<br /> negociables, significa que ellos pueden y deben ser discutidos por el cliente y el proveedor.<br /> <br /> ==SOBRE EL PROYECTO==<br /> Este documento fue creado por la fundación OWASP (Open Web Application Security Project por sus siglas en Inglés), una organización caritativa sin animos de lucro con el objetivo de crear herramientas y documentación, gratuita y abierta para asegurar software. Para facilitar su uso en contratación privada, este documento es de dominio publico. Puede encontrar detalles adicionales sobre este proyecto en http://www.owasp.com/index.php/OWASP_Legal_Project. Son Bienvenidos comentarios de ambos, productores y consumidores de software, asi como de la comunidad legal.<br /> <br /> OWASP reconoce gratamente la contribución especial de [http://www.aspectsecurity.com Aspect Security] por su rol en la investigación y preparación de este documento.<br /> <br /> ==OBJECIONES==<br /> <br /> Las siguientes páginas cubren algunas objeciones que escuchamos frecuentemente sobre usar este lenguaje en contratos de desarrollo de software:<br /> <br /> ===PERO NO TODOS LOS TÉRMINOS SON CORRECTOS PARA NOSOTROS…===<br /> <br /> Este documento debe ser considerado un punto de inicio para su contrato. Puede que no le gusten todas las actividades, o puede querer proponer mas. Puede querer asignar responsabilidades de manera diferente. Este document no pretende capturar exactamente las necesidades de todos los clientes y proveedores de software. Pretende proveer un marco para discutir temas clave, importantes para asegurarse que el software se cree seguro. Despues de que tengan una discusión sobre seguridad y alcancen un acuerdo. Puede ajustar el convenio para que concuerde con el contrato.<br /> <br /> ===PERO, ¿QUIEN DEBE PAGAR POR ESTAS ACTIVIDADES?…===<br /> <br /> Este contrato no es sobre poner mas peso al desarollo de software. La pregunta no es sobre si hay costos asociados con seguridad (por supuesto que hay). Sino, la pregunta correcta es que actividades deberían hacerse por ambas partes para minimizar costos, y cuando deberían ocurrir.<br /> <br /> Este anexo no menciona (intensionalmente) sobre el detalle de quien debería pagar por la actividades descritas. Mientras muchas de estas actividades deben estar pasando ya, y son esperadas por muchos clientes, ellas no estan practicadas regularmente en la industria del software. La cuestion de quien paga (y cuando) debe ser parte de la negociación.<br /> <br /> Calcular el costo de la seguridad es muy difícil. Auque hay costos asociados con realizar actividades de seguridad, hay también costos importantes asociados con ignorar estas actividades. Estamos convencidos el mejor costo-beneficio para desarrollar software es reducir la probabilidad de que fallas de seguridad sean introducidas y minimzar el tiempo entre introducir una falla y arreglarla.<br /> <br /> Una distición importante a hacer cuando calculamos costos es entre construir mecanismos de seguridad y las actividades para asegurarse que esos mecanismos sean correctos y efectivos. Intentar agregar mecanismoa al final de el ciclo de desarrollo puede causar serios problemas de diseño e incrementará el costo dramáticamente. Este convenio promieve decisiones sobre mecanismos para minimizar estos costos. Similarmente, esperas hasta justo antes de la publicación para hacer actividades de aseguramiento, tales como revisión de código y pruebas de intrudión, tambien incrementaría los costos dramaticamente. Creemos que el mejor costo-beneficio para ganar certeza es poner un nivel constante de esfuerzo en el aseguramiento a través del ciclo de desarrollo.<br /> <br /> ===PERO EL NIVEL DE RIGOR ESTA INCORRECTO….===<br /> <br /> Este convenio asume que el software que esta siendo desarrollado es rasonablemente importante para una empresa grande o agencia de gobierno. Hemos seleccionado un &quot;nivel de rigor&quot; para el convenio que es alcanzable por la mayoria de las organizaciones proveedoras de software, e identificaría y manejaría los riesgos más comunes.<br /> <br /> Sin embargo, para el software que va a ser usado en aplicaciones críticas, como aplicaciones médicas, financieras o relacionadas con el ejército. Puede querer incrementar el nivel de rigor. Puede querer agregar revisiones, documentación y actividades adicionales de prueba. Puede querer mejorar el proceso de encontrar, diagnosticar y remediar vulnerabilidades. Para aplicaciones menos sensibles, puede desear reducir o remover actividades.<br /> <br /> ===PERO NOSOTROS NO PODEMOS ACEPTAR TANTO RIESGO…===<br /> Este convenio pretende facilitar la discusión sobre quien tomaría el riesgo por las vulnerabilidades de seguridad en el software. Por un lado del espectro, el cliente podria tomar todo el riesgo y el proveedor podria entregar código con muchas vulnerabilidades. Por el otro extremo, el proveedor podría tomar todo el riesgo y asumir la responsabilidad de entregar código perfecto. Ambos extremos son irrealizables.<br /> <br /> Actualmente, en este convenio, el proveedor toma el riesgo por problemas que sean descubiertos en los requerimientos o deben ser cubiertos por esfuerzos razonables en pruebas. Pero la remediación de &quot;nuevos&quot; problemas de seguridad tendría que ser pagado por el cliente. Creemos que este es un equilibrio funcional, ya que limita el riesgo adquirido por el proveedor y promueve obtener requerimientos de seguridad por anticipado. Pero hay muchas otras posibles soluciones a este problema. Por favor, dejenos saber si tiene sugerencias alternas, podriamos incluirlas en versiones futuras de este documento.<br /> <br /> Note que la discusión aqui solo cubre el riesgo asociado con arreglar las vulnerabilidades de seguridad en el código, y no incluye los costos asociados con recuperarse de incidentes de seguridad relacionados con explotar cualquiera de esas vulnerabilidades. Estamos interesados en mejores prácticas en esta area.<br /> <br /> ===PERO COMO PODEMOS ASEGURAR CÓDIGO DE TERCEROS…===<br /> <br /> Casi todos los proyectos de sofware tienen una cantidad importante de código de terceros como librarieas, frameworks y productos. Desde la perspectiva de seguridad, este código es tan importante como el código desarrollado a la medida para su proyecto.<br /> Creemos que la responsabilidad de asegurar la seguridad de este código es llevada mejor por el proveedor, aunque ellos podrían no tener toda la capacidad para garantizar la seguridad por ellos mismos. Sin embargo, La seguridad puede ser parte de el la desición de &quot;construir o comprar&quot;, y esta parece ser la mejor manera de promoverla.<br /> <br /> El proveedor, por supuesto, tiene la opción de pasar la responsabilidad a el proveedor del software de terceros. El desarrolador puede tambien analizar el código de terceros por él mismo o contratar expertos en seguridad para analizarlo por él.<br /> <br /> ===PERO PORQUE DEBO PASAR POR TODO ESTE PROBLEMA…===<br /> <br /> En última instancia, creemos que no hay alternativa para hacer de la seguridad una parte de el proceso de contratación de software. Actualmente, creemos que hay serios malentendidos sobre la seguridad del código que esta siendo desarrollado bajo muchos contratos de desarrollo de software. Esto puede solamente llevar a una cara litigación y a desiciones hechas por individuos con poca experiencia y entendimiento sobre software. Lea el [[Secure software contracting hypothetical case study | Caso de estudio hipotético sobre contratación de software seguro]] para una discusión completa de este problema.<br /> <br /> Hay muchos beneficios al trabajar con este convenio. El principal es que pondrá claras las expectativas entre las partes involucradas. En algunos casos ayudará a evitar demandas cuando problemas de seguridad difíciles aparecen en el software. Tambien, estan son las mismas actividades requeridas por muchas razónes legales y de conformidad con estándares/leyes.<br /> <br /> ===PERO ES MUY DIFÍCIL PRODUCIR TODA ESTA DOCUMENTACIÓN…===<br /> <br /> OWASP no promueve la documentacion por la simpre documentacion. Este convenio esta enfocado en promover la calidad, no la cantidad. Creemos que puede ser posible (en algunos proyectos) cumplir con este contrato con una pequeña evaluacion de riesgo, algunas páginas de requerimientos, un pequeño documento de diseño de seguridad, un plan de pruebas, y algunos resultados de pruebas.<br /> <br /> El objetivo de esta documentación es simplemente asegurar, en cada etapa del desarrollo de software, que se ha puesto la atención apropiada en la seguridad. Un beneficio adiciona es que esta documentacion puede ser recolectada en conjunto para formar un &quot;paquete de certificación&quot; que básicamente esbose el argumento de porque deberiamos confiar que el software hará lo que dice.<br /> <br /> ==ANEXO DE CONTRATO==<br /> <br /> ===1. INTRODUCCIÓN===<br /> <br /> Esta anexo esta hecho para _____________________ (&quot;convenio&quot;) entre el Cliente y el proveedor. Tanto el Cliente como el proveedor acuerdan maximisar la seguridad del software de acuerdo a los siguientes términos.<br /> <br /> <br /> ===2. FILOSOFÍA===<br /> <br /> Esta anexo pretende aclarar los derechos y obligaciones relacionados a seguridad de todas las partes en una relacion de desarrollo de software. Al mayor nivel, las partes acuerdan que:<br /> <br /> ;(a) Las desiciones de seguridad estarán basadas en el riesgo : Las desciciones sobre la seguridad seran tomadas en conunto por el cliente y el proveedor basandose en un firme entendimiento de el riesgo involucrado. <br /> <br /> ;(b) Las actividades de seguridad estarán balanceadas : El esfurzo de seguridad será distribuido equitativamente a través de todo el ciclo de desarollo de software.<br /> <br /> ;(c) Las actividades de seguridad estarán integradas : Todas las actividades y documentación discutidas aqui pueden y deben ser integradas dentro del ciclo de desarrollo de software del proveedor y no mantenerse separadas de el resto del proyecto. Nada en este anexo implica algún processo de desarrollo de software en particular.<br /> <br /> ;(d) Se esperan vulnerabilidades : Todo software contiene defectos, y algunos de estos crearan problemas de seguridad. Ambos, cliente y proveedor se esforzará para identificar las vulnerabilidades tan pronto como sea posible en el ciclo de desarrollo.<br /> <br /> ;(e) La información sobre seguridad será comunicada por completo : Toda la información relevante para la seguridad se compartirá entre el cliente y el proveedor inmediatamente y completamente.<br /> <br /> ;(f) Se requerirá solo documentacion de seguridad necesaria : La documentación de seguridad no necesita ser demasiado amplia para describir claramente el diseño de seguridad, análisis de riesgo y problemas.<br /> <br /> ===3. ACTIVIDADES EN EL CICLO DE DESARROLLO===<br /> <br /> ;(a) Entendimiento del Riesgo : El proveedor y el cliente acuerdan trabajar juntos para entender y documentar los riesgos que enfrenta la aplicacion. Este esfuerzo debe identificar los riesgos clave para los activos y funciones importantes que provee la aplicación. Cada uno de los temas listados en la sección de requerimientos debe ser considerado.<br /> <br /> ;(b) Requerimientos : Basado en los riesgos, El proveedor y cliente acuerda trabajar juntos para crear requerimientos de seguridad detallados como parte de la especificacion de el software a ser desarrollado. Cada uno de los temas listados en la sección de requerimientos de este anexo deben ser discutidos y evaluados por ambos, cliente y proveedor. Estos requerimientos pueden ser satisfechos por software creado a la medida, software de terceros, o la plataforma. <br /> <br /> ;(c) Diseño : el desarollador acuerda proveer documentation que explique claramente el diseño para adquirir cada uno de los requerimientos de seguridad. En muchos de los casos, esta documentacion describirá los mecanismos de seguridad, donde se incluiran dentro de la arquitectura, y todos los patrones de diseño relevantes para asegurar su uso adecuado. El diseño debe especificar claramente si tales mecanismos vienen de software a la medida, software de terceros o de la plataforma.<br /> <br /> ;(d) Implementación : El proveedor acuerda entregar y seguir un conjunto de lineamientos de codificación segura. Estos lineamientos indicarán como sele de debe dar formato, estructurar y comentar el código fuente. Todo código relacionado a seguridad debe ser comentado profundamente. Guías sobre como evitar vulnerabilidades se seguridad comunes debe ser incluida. Tambien, todo el código debe ser revisado por al menos otro desarollador basandose en los requerimientos de seguridad y los lineamientos de codificación antes de ser conciderado listo para pruebas unitarias.<br /> <br /> ;(e) Pruebas y análisis de seguridad : El proveedor acuerda entregar y seguir un plan de pruebas de seguridad que defina como se realizarán las pruebas o bien establecer como cada uno de los requerimientos de seguridad va a ser complido. El nivel de rigor de esta actividad debe ser considerado y detallado en un plan. El proveedor ejecutará el plan de prueba y proveera los resultados a el cliente.<br /> <br /> ;(f) Publicación segura : El proveedor acuerda entregar lineamientos de configuración segura que describan completamente todas las opciones de configuracion relacionadas con seguridad y sus implicaciones para la seguridad del software en su conjunto. Los lineamientos deben incluir una descripción completa de las dependencias en la plataforma y como deben ser configuradas de manera segura, incluidas las del sistema operativo, servidor Web y servidor de aplicacion. La configuracion predeterminada del software debe ser segura.<br /> <br /> ===4. ÁREAS CON REQUERIMIENTOS DE SEGURIDAD===<br /> <br /> Los siguientes temas/áreas deben ser considerados durante las actividades de entendimiento de riesgo y definición de requerimientos. Este esfuerzo debe producir un conjunto de requerimientos ajustados, especificos y probables. Ambos, proveedor y cliente deben ser involucrados en este proceso y deben ponerse de acuerdo sobre el conjunto final de requerimientos.<br /> <br /> ;(a) Validación de entradas y condificación : Los requerimientos deben especificar las reglas para canonicalización, validación y codificación de cada dato de entrada a la aplicación, ya sea de usuarios, sistemas de archivos, bases de datos o sistemas externos. La regla predeterminada debe ser que todas las entradas sean validadas a menos que cumplan con una especificacion detallada de que esta permitido. Además, los requerimientos deben especificar las acciones a tomar cuando se reciven entradas no válidas. Especificamente, la aplicación no debe ser susceptible a inyecciones, desbordamientos, manipulación y otros ataques con entradas de usuario corruptas.<br /> <br /> ;(b) Autentificación y manejo de sessiones : Los requerimientos deben especificar como se protegeran las credenciales para autentificación y los identificadores de sesión a través del ciclo de desarrollo de software. Los requerimientos para todas las funciones relacionadas deben ser agregadas incluyendo recuperar contraseñas, cambio de contraseñas, recordar contraseñas, desconexión y conexión multiple.<br /> <br /> ;(c) Control de Acceso : Los requerimientos deben incluir una descripcion detallada de todos los roles (grupos, privilegios, autorizaciones) usadas en la aplicación. Los requerimientos deben indicar todos los activos y funciones que provee la aplicacion. Los requerimientos deben especificar detallada y exactamente los derechos de acceso para cualquier activo y función de cada rol. Se sugiere utilizar un formato de matriz de control de acceso para documentar estas reglas.<br /> <br /> ;(d) Manejo de Errores : Los requerimientos deben detallar como se van a manejar los errores que ocurran dentro del procesamiento. Algunas aplicaciones deberían hacer lo mejor posible en caso de un error, mientras que otras deberían terminar su procesamiento inmediatamente.<br /> <br /> ;(e) Historial : Los requerimientos deben especificar que eventos son relevantes para la seguridad y necesitan ser registrados, como ataques detectados, intentos de conexión fallidos e intentos de exeder la autorización. Los requerimientos deben especificar tambien que information registrar con cada evento, incluyendo hora y fecha, descripción del evento, detalles de aplicación, y otra información útil en esfuerzos forences.<br /> <br /> ;(f) Conexiones a sistemas externos : Los requerimientos deben especifica como la autentificación y cifrado será manejado para todos los systemas externos, tales como bases de datos, directorios y servicios Web. Todas las credenciales requeridas para la comunicación con sistemas externos deben almacenarce cifradas y fuera de el código dentro de archivos de configuración. <br /> <br /> ;(g) Cifrado : Los requerimientos deben especificar que datos deben ser cifrados, como serán cifrados y como todos los certificados y otras credenciales deben ser manejadas. Las aplicaciones deben usar algoritmos estándar implementados en una librerias de cifrado que hayan sido usadas y probadas ampliamente.<br /> <br /> ;(h) Disponibilidad : Los requerimientos deben especificar como protegerse de ataques de negación de servicio. Todos los posibles ataques en la aplicacion deben ser considerados, incluyendo bloqueos de auntentificación, agotamiento de conexiones y otros ataques de agotamiento de recursos.<br /> <br /> ;(i) Configuración segura : Los requerimientos deben especificar que los valores predeterminados para todas las configuraciones relacionadas a seguridad deben ser seguras. Para propósitos de auditoría, el software deberia ser capás de producir un reporte sencillo de leer que muestre los detalles de todas las configuraciones relacionadas con seguridad.<br /> <br /> ;(j) Vulnerabilidades especificas : Los requerimientos deben incluir un conjunto de vulnerabilidades especificas que no deben estar presentes en el software. A menos que sea especificado de otra manera, el software no debe incluir ninguna de las fallas descritas en el la &quot;Lista de OWASP sobre las 10 vulnerabilidades mas críticas en aplicaciones Web&quot;.<br /> <br /> ===5. PERSONAL Y ORGANIZACIÓN===<br /> <br /> ;(a) Arquitecto en seguridad : El desarollador asignará la responsabilidad por la seguridad a un solo recurso técnico experimentado, para ser conocido como el arquitecto de seguridad del proyecto. El arquitecto de seguridad certificará la seguridad de cada entregable.<br /> <br /> ;(b) Entrenamiento en Seguridad : el proveedor será responsable de verificar que todos los miembros del equipo de desarrollo han sido entrenados en tecnicas de programación segura.<br /> <br /> ;(c) Desarrolladores dignos de confianza : El proveedor acuerda realizar las investigaciones de antecendentes apropiadas a todos los miembros del equipo de desarrollo.<br /> <br /> ===6. AMBIENTE DE DESARROLLO===<br /> <br /> ;(a) Codificación segura : El proveedor debe mencionar que herramientas se usarán en el ambiente de desarrollo de software para promover la codificación segura.<br /> <br /> ;(b) Adminstración de configuración : El proveedor debe usar un sistema de control de versiones que autentifique y registre el miembro del equipo asociado con todos los cambios en el código base, todos los archivos de configuración y compilación.<br /> <br /> ;(c) Distribución : El proveedor debe usar un proceso de compilación que construya confiablemente un archivo de distribución completo desde el código fuente. Este proceso debe incluir un método para verificar la integridad de el software entregado al cliente.<br /> <br /> ===7. LIBRERIAS, MARCOS DE DESARROLLO Y PRODUCTOS===<br /> <br /> ;(a) Apertura : El proveedor debe mencionar todas los aplicaciones de terceros usadas en el software, incluyendo todas las librerias, marcos de desarrollo, componentes y otros productos, ya sean comerciales, gratuitos, de código abierto o código cerrado.<br /> <br /> ;(b) Evaluación : El proveedor debe hacer esfuerzos rasonables para asegurar que el sofware de terceros cumple con todos los términos de este contrato y es tan seguro como el código a la medida desarrollado bajo este contrato.<br /> <br /> ===8. REVISIONES DE SEGURIDAD===<br /> <br /> ;(a) Derecho de revisión : El cliente tiene el derecho mandar revisar el software para buscar fallas de seguridad, esto a sus expesas y en cualquier momento dentro de los 60 dias despues de la entrega. El desarrollador acepta proveer apoyo rasonable al equipo de revisión proveyendo el codigo fuente y acceso a los ambientes de pruebas.<br /> <br /> ;(b) Covertura de la revisión : Las revisiones de seguridad deben cubrir todos los aspectos de el software entregado, incluyendo código a la medida, componentes, productos y configuración de sistema.<br /> <br /> ;(c) Alcance de la revisión : Al menos, la revisión debe cubrir todos los requerimientos de seguridad y debería buscar otras vulnerabilidades comunes. La revisión puede incluir una combinación de busqueda automatizada de vulnerabilidades, pruebas de intrusión, análisis estático de código fuente y revisión de código por expertos.<br /> <br /> ;(d) Problemas encontrados : Los problemas de seguridad descubiertos serán reportados a el cliente y proveedor por igual. A todos los problemas se les dará seguimiento y serán reparados como se especifique en la sección de seguimiento de problemas de seguridad de este anexo.<br /> <br /> ===9. ADMINISTRACIÓN DE PROBLEMAS DE SEGURIDAD===<br /> <br /> ;(a) Identificación : El proveedor dara seguimiento a todos los problemas de seguridad descubiertos en todo el ciclo de desarrollo, ya sea un problema en los requerimientos, diseño, implementación, pruebas, publicación u operación. El riesgo asociado con cada problema de seguridad será evaluado, documentado y reportado a el cliente tan pronto como sea posible.<br /> <br /> ;(b) Protección : El proveedor protegerá apropiadamente la información relacionada a problemas de seguridad y la documentación relacionada a ellos, esto, para ayudar a disminuir la probabilidad de las vulnerabilidades en el software operacioneal del cliente sean expuestas.<br /> <br /> ;(c) Reparación : Los problemas de seguridad que sean indentificados antes de la entrega deben ser reparados por el proveedor. Los problemas de seguridad descubiertos despues de la entrega deben ser manejados en la misma manera que otros problemas funcionales según lo especificado en este contrato.<br /> <br /> ===10. CERTEZA===<br /> <br /> ;(a) Certeza : El proveedor proveera un &quot;paquete de certificación&quot; consistente en la documentación de seguridad creada a traves del proceso de desarrollo. El paquete deberá establecer que los requerimientos de seguridad, diseño, implementación y resultados de pruebas fueron completados apropiadamente y todos los problemas de seguridad fueron resueltos apropiadamente.<br /> <br /> ;(b) Auto-Certificación : El aquitecto de seguridad certificará que el software cumple con los requerimientos de seguridad, que todas las actividades de seguridad se realizaron, y que todos los problemas de seguridad identificados han sido documentados y resueltos. Cualquier excepción a el estado de la certificacion debe estar totalmente documentada al momento de la entrega.<br /> <br /> ;(c) No código malicioso : El proveedor garantize que el sofware no debe contener ningun código que no se alinee a algun requerimiento del software y debilite la seguridad de la aplicación, incluyendo viruses, gusanos, bombas de tiempo, puertas traseras, caballos de troya, huevos de pascua y cualquier otra forma de código malicioso.<br /> <br /> ===11. CONCENTIMIENTO Y MANTENIMIENTO DE LA SEGURIDAD===<br /> <br /> ;(a) Consentimiento : El software no debe ser considerado como aceptado hasta que el paquete de certificación este completo y todos los problemas de seguridad han sido resueltos.<br /> <br /> ;(b) Investigación de problemas de seguridad : Despues del concentimiento, si se sospecha (razonablemente) o descubren problemas de seguridad, el proveedor deberá asisitir al cliente en realizar una investigación para determinar la naturaleza del problema. El problema debe ser considerado &quot;nuevo&quot; si no es cubierto por los requerientos de seguridad y esta fuera de el alcance (razonable) de las pruebas de seguridad.<br /> <br /> ;(c) Problemas de seguridad nuevos : El proveedor y el cliente consientes en medir el alcance y esfuerzo requerido para resolver problemas de seguridad nuevos, y negociad de buena fe para alcanzar un acuerdo y realizar el trabajor requerido para solucionarlos.<br /> <br /> ;(d) Otros problemas de seguridad : El proveedor debe usar todos los esfuersos comercialmente rasonables consistentes con practicas de desarrollo comunes en la industria, tomando en cuenta la severidad de el riesgo, para resolver todos los problemas de seguridad considerados nuevos tan pronto como sea posible.<br /> <br /> [[Category:OWASP Legal Project]]<br /> <br /> __NOTOC__</div>

Jorge Correa https://wiki.owasp.org/index.php?title=Diez_Mayores_2007&diff=76480 2010-01-18T19:42:21Z

<p>Jorge Correa: /* Conclusión */</p> <hr /> <div>{{Top_10_2007:TopTemplate|usenext=NextLink|next=-Metodología|useprev=Nothing|usemain=Nothing}}<br /> <br /> ==Presentación==<br /> <br /> Bienvenidos a la lista de las 10 mayores vulnerabilidades de OWASP 2007! Esta edición, totalmente reescrita lista las vulnerabilidades más serias en aplicaciones web, discute como protegerse de ellas y provee ligas a mas información. '''La lista de las 10 mayores vulnerabilidades de OWASP ha sido traducida al Español. [https://www.owasp.org/images/a/ae/OWASP_Top_10_2007_Spanish.pdf De clic aquí] para la traducción al español!'''<br /> <br /> La lista de las 10 mayores de OWASP para la versión empresarial de Java esta disponible para bajarla [https://www.owasp.org/images/8/89/OWASP_Top_10_2007_for_JEE.pdf aqui]<br /> <br /> == Objetivo ==<br /> <br /> '''El objetivo principal de la lista de las 10 de OWASP es formar desarrolladores, diseñadores, arquitectos y organizaciones''' sobre las consecuencias de las vulnerabilidades más comunes en aplicaciones web. Las lista provee métodos básicos para protegerse contra estas vulnerabilidades - un gran inicio para su programa de codificación segura.<br /> <br /> '''La seguridad no es un evento de una sola vez'''. No es suficiente asegurar su código solo una vez. Para 2008, esta lista cambiará y sin cambiar una línea de el código de su aplicación, puede ser vulnerable. Por favor revise el consejo en [[Top_10_2007-Where to Go From Here|Top 10 2007-¿A dondé sigo Ahora?]] para mas información.<br /> <br /> '''Una iniciativa de codificación segura debe lidiar con todas las etapas de desarrollo del programa'''. Las aplicaciones Web seguras '''''solo''''' es posible cuando un SDLC seguro es usado. Los programas seguros desde el inicio por su diseño y desarrollo. Hay al menos 300 problemas que afectan la seguridad en general de una aplicación Web. Estos mas de 300 problemas están detallados en la [http://www.owasp.org/index.php/OWASP_Guide_Project Guía de OWASP], la cua es una lectura escencial para cualquiera que desarolle aplicaciones Web en la actualidad.<br /> <br /> '''Este documento es el principalmente un documento educativo, no un standard'''. Por favor no adopte este documento como una política o estándar sin [mailto:owasp@owasp.org hablar con nosotros] primero! Si necesita una política o estandar de codificación segura, OWASP tiene proyectos de políticas y estándares de seguridad que están en progreso. Por favor considere unirse o asistir financieramente estos esfuerzos.<br /> <br /> == Retroalimentación ==<br /> <br /> {| <br /> |-<br /> <br /> |Agradecemos a [http://www.mitre.org/ MITRE] por hacer ''La distribución de tipos de vulnerabilidades en el [http://cve.mitre.org/ CVE]'' disponibles libremente para su uso. El proyecto de la lista de las 10 mayores esta dirijida y patrocinada por [http://www.aspectsecurity.com https://www.owasp.org/images/d/d1/Aspect_logo.gif].<br /> |}<br /> <br /> Líder de proyecto: Andrew van der Stock (Director ejecutivo, Fundación OWASP)<br /> Co-autores: Jeff Williams (Presidencia, Fundación OWASP), Dave Wichers (Presidencia de conferencia, Fundación OWASP)<br /> <br /> Queremos agradecer a los revisores:<br /> <br /> *Raoul Endres por ayudar a echar a andar la lista de nuevo y por sus valiosos comentarios.<br /> *[mailto:coley...at...mitre.org Steve Christey](MITRE) por una importante revisión y la adición de los datos del MITRE CWE<br /> *[http://jeremiahgrossman.blogspot.com/ Jeremiah Grossman] ([http://www.whitehatsec.com/ WhiteHat Security]) por revisar y contribuir con información sobre el éxico (o falla) de la medidas de detección automatizadas.<br /> *[http://www.smithline.net/ Neil Smithline] ([http://www.bea.com/ BEA Systems]) por sus comentarios y producir la versión Wiki-<br /> *Sylvan von Stuppe por una revisión ejemplar.<br /> *Colin Wong, Nigel Evans y Andre Gironda por comentarios enviados por correo.<br /> <br /> == Conclusión ==<br /> <br /> {| border='1' cellpadding='2' <br /> |- <br /> |[[Top 10 2007-Secuencia de Comandos en Sitios Cruzados (XSS)|A1 - Secuencia de comandos en sitios cruzados (XSS)]]<br /> |Las fallas de XSS acurren cuando una aplicación toma la información proveida por el usuario y la envia a un navegador sin validarla primero o codificar el contenido. El XSS permite a los atacantes ejecurar scripts en el navegador de la víctima la cual puede secuestrar la sesión del usuario, modificación de sitios web, la posible introducción de gusanos, etc.<br /> |-<br /> <br /> |[[Top 10 2007-Fallas de Inyección|A2 - Inyección de código]]<br /> |La fallas de inyección, particularmente la inyección de SQL, son comunes en las aplicaciones Web. La inyección ocurre cuando los datos proveidos por el usuario son enviados a un interprete como parte de un comando o petición. Los datos hostiles del atacante engañan al interprete a ejecutar comandos no intencionados o cambiar los datos.<br /> |-<br /> <br /> |[[Top 10 2007-Ejecución de Ficheros Malintencionados|A3 - Ejecución maliciosa de archivos]]<br /> |El código vulnerable a inclusión remota de archivos permite a los atacantes incluir código y datos hostiles, resultando en ataques devastadores, como secuestro total del servidor. Los ataques de ejecución maliciosa de archivos afectan a PHP, XML y cualquier marco de trabajo que soporte el manejo de nombres de archivos o permita la interacción con los usuarios mediante el intercambio de archivos.<br /> |-<br /> <br /> |[[Top 10 2007-Referencia Insegura y Directa a Objetos|A4 - Referencia directa e insegura a objetos]]<br /> |Una referencia directa e insegura a objetos ocurre cuando un desarrollador expone una referencia a una implementación interna de un objeto como unn archivo, un directorio, un registro de BD o una llave, en forma de parámetro de URL o de una forma. Los atacantes pueden manipular esas referencias para acceder a otros objetos sin tener autorización<br /> |-<br /> <br /> |[[Top 10 2007-Vulnerabilidades de Falsificación de Petición en Sitios Cruzados (CSRF)|A5 - Falsificación de petición en sitios crusados (CSRF)]]<br /> |A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.<br /> <br /> |-<br /> <br /> |[[Top 10 2007-Revelación de Información y Gestión Incorrecta de Errores|A6 - Revelación de Información y Gestión Incorrecta de Errores]]<br /> |Las aplicaciones pueden (sin intención) revelar información sobre su configuración, funcionalidad interna o violar la privacidad a travez de una variedad de problemas de la aplicación. Los atacantes usan estas debilidades para robar información delicada o conducir ataques mas serios. <br /> |-<br /> <br /> |[[Top 10 2007-Autenticación y Gestión de Sesiones Disfuncional|A7 - Autentificación y gestión de sesiones disfuncional]]<br /> |Las credenciales de las cuenta y testigos de sesión son frecuentemente protegidos inadecuadamente. Los atacantes roban contraseñas, llaves o testigos de autneticación para asumir la identidad de otros usuarios.<br /> |-<br /> <br /> |[[Top 10 2007-Almacenamiento Criptográfico Inseguro|A8 - Almacenamiento cirptográfico inseguro]]<br /> |Las aplicaciones Web raramente usan funciones criptográdicas apropiadamente para proteger información y credenciales. Los atacantes usan la información mal protegida para hacer robos de identidad y otros crimenes, como fraude con tarjetas de crédito.<br /> |-<br /> <br /> |[[Top 10 2007-Comunicaciones inseguras|A9 - Comunicación Insegura]]<br /> |Las aplicaciones frecuentement falla al cifrar el tráfico de red cuando es necesario proteger comunicaciones delicadas.<br /> |-<br /> <br /> |[[Top 10 2007-Falla de restricción de acceso a URL|A10 - Falla de restricción de acceso a URL]]<br /> |Frecuentemente, una aplicacion solo protege funcionalidad delicada evitando mostrar la ligas o URLs a usuarios no autorizados. Los atacantes pueden usar esta debilidad para acceder y realizar operaciones no autorizadas al acceder a esas URLs directamente.<br /> |}<br /> '''&lt;center&gt;Tabla 1: La 10 mayores vulnerabilidades de OWASP 2007&lt;/center&gt;'''<br /> <br /> <br /> Hay muchas páginas en este documento que no están dedicadas a vulnerabilidades en específico y por lo tanto no están listadas en la tabla. Aqui hay una lista de ellas.<br /> <br /> {| border='1' cellpadding='2' <br /> |- <br /> |[[Top 10 2007]]<br /> |Ademas de proveed una presentación, y un marcador de la sección de &quot;conclusiones&quot; (esto puede hacerse arrastrando [https://www.owasp.org/index.php/Top_10_2007#Summary este enlace] a sus favoritos) nos da acceso rápido a el documento completo.<br /> |-<br /> |[[Top 10 2007-Metodología]]<br /> |Una descripción de la metodología usada para selecionar las vulnerabilidades para este documento.<br /> |-<br /> |[[Top 10 2007-¿A dondé sigo Ahora?]]<br /> |Algunas sugerencias sobre como proceder una ves que ha leído este documento.<br /> |-<br /> |[[Top 10 2007-Referencias]]<br /> |Recomendaciones para lectura posterior.<br /> |}<br /> '''&lt;center&gt;Tabla 1a: Paginas en el documento de la ''lista de las 10 mayores 2007'' que no son la lista de vulnerabilidades mencionadas arriba.&lt;/center&gt;'''<br /> <br /> ==Una nota sobre las diferentes versiones==<br /> Mientras que la única versión oficial de la ''lista de las 10 mayores vulnerabilidades de OWASP 2007'' es la version en PDF y en inglés, OWASP ah puesto a su disposición este Wiki que inicialmente contenia el mismo contenido que el PDF. Pero OWASP espera que cambien con su ayuda. OWASP promueve el envolvimiento de la comunidad y quiere su ayuda para hacer la versión Wiki mejor que nunca. Para ayudar a esto han creado un pequeño [[Editing:Top_10_2007|tutorial]] para iniciarlo en este proceso.<br /> <br /> ==Versiones para bajar==<br /> Puede bajar la lista 2007 (versión final) aqui:<br /> <br /> * [http://www.owasp.org/images/e/e8/OWASP_Top_10_2007.pdf (PDF, 930 kb)]<br /> &lt;!--* [http://www.owasp.org/images/2/24/OWASP_Top_10_2007.doc (Word, 514 kb)]--&gt;<br /> <br /> * [https://www.owasp.org/images/a/ae/OWASP_Top_10_2007_Spanish.pdf (Español PDF, 488kb)]<br /> <br /> * [https://www.owasp.org/images/c/ce/OWASP_Top_10_2007_-_French.pdf (Francés PDF, 455 kb)]<br /> <br /> * [http://www.metasecurity.org/owasp/OWASP_Top_10_2007_Korean.pdf (Koreano PDF, 768 kb)]<br /> <br /> * [http://csirt.ulakbim.gov.tr/dokumanlar/Ceviri_OWASP_ilk10_2007.pdf (Turco PDF, 718 kb)]<br /> <br /> * [http://www.owasp.org/images/4/42/OWASP_TOP_10_2007_PT-BR.pdf (Portuguese Brasileño PDF, 329 kb)]<br /> <br /> * [https://www.owasp.org/images/8/89/OWASP_Top_10_2007_for_JEE.pdf OWASP Top 10 para la versión empresarial de Java (PDF, 630 kb)]<br /> <br /> * Le gustaría tener esta versión en otro idioma? podriamos usar su ayuda para traducirla. Contacte a Andrew van der Stock (vanderaj ...(@)... owasp.org) para ayudarnos a traducir la lista de las 10 mayores a otro idioma.<br /> <br /> {{Top_10_2007:BottomTemplate|usenext=NextLink|next=-Metodología|useprev=Nothing|usemain=Nothing}}</div>

Jorge Correa https://wiki.owasp.org/index.php?title=Diez_Mayores_2007&diff=76479 2010-01-18T19:40:36Z

<p>Jorge Correa: /* Conclusión */</p> <hr /> <div>{{Top_10_2007:TopTemplate|usenext=NextLink|next=-Metodología|useprev=Nothing|usemain=Nothing}}<br /> <br /> ==Presentación==<br /> <br /> Bienvenidos a la lista de las 10 mayores vulnerabilidades de OWASP 2007! Esta edición, totalmente reescrita lista las vulnerabilidades más serias en aplicaciones web, discute como protegerse de ellas y provee ligas a mas información. '''La lista de las 10 mayores vulnerabilidades de OWASP ha sido traducida al Español. [https://www.owasp.org/images/a/ae/OWASP_Top_10_2007_Spanish.pdf De clic aquí] para la traducción al español!'''<br /> <br /> La lista de las 10 mayores de OWASP para la versión empresarial de Java esta disponible para bajarla [https://www.owasp.org/images/8/89/OWASP_Top_10_2007_for_JEE.pdf aqui]<br /> <br /> == Objetivo ==<br /> <br /> '''El objetivo principal de la lista de las 10 de OWASP es formar desarrolladores, diseñadores, arquitectos y organizaciones''' sobre las consecuencias de las vulnerabilidades más comunes en aplicaciones web. Las lista provee métodos básicos para protegerse contra estas vulnerabilidades - un gran inicio para su programa de codificación segura.<br /> <br /> '''La seguridad no es un evento de una sola vez'''. No es suficiente asegurar su código solo una vez. Para 2008, esta lista cambiará y sin cambiar una línea de el código de su aplicación, puede ser vulnerable. Por favor revise el consejo en [[Top_10_2007-Where to Go From Here|Top 10 2007-¿A dondé sigo Ahora?]] para mas información.<br /> <br /> '''Una iniciativa de codificación segura debe lidiar con todas las etapas de desarrollo del programa'''. Las aplicaciones Web seguras '''''solo''''' es posible cuando un SDLC seguro es usado. Los programas seguros desde el inicio por su diseño y desarrollo. Hay al menos 300 problemas que afectan la seguridad en general de una aplicación Web. Estos mas de 300 problemas están detallados en la [http://www.owasp.org/index.php/OWASP_Guide_Project Guía de OWASP], la cua es una lectura escencial para cualquiera que desarolle aplicaciones Web en la actualidad.<br /> <br /> '''Este documento es el principalmente un documento educativo, no un standard'''. Por favor no adopte este documento como una política o estándar sin [mailto:owasp@owasp.org hablar con nosotros] primero! Si necesita una política o estandar de codificación segura, OWASP tiene proyectos de políticas y estándares de seguridad que están en progreso. Por favor considere unirse o asistir financieramente estos esfuerzos.<br /> <br /> == Retroalimentación ==<br /> <br /> {| <br /> |-<br /> <br /> |Agradecemos a [http://www.mitre.org/ MITRE] por hacer ''La distribución de tipos de vulnerabilidades en el [http://cve.mitre.org/ CVE]'' disponibles libremente para su uso. El proyecto de la lista de las 10 mayores esta dirijida y patrocinada por [http://www.aspectsecurity.com https://www.owasp.org/images/d/d1/Aspect_logo.gif].<br /> |}<br /> <br /> Líder de proyecto: Andrew van der Stock (Director ejecutivo, Fundación OWASP)<br /> Co-autores: Jeff Williams (Presidencia, Fundación OWASP), Dave Wichers (Presidencia de conferencia, Fundación OWASP)<br /> <br /> Queremos agradecer a los revisores:<br /> <br /> *Raoul Endres por ayudar a echar a andar la lista de nuevo y por sus valiosos comentarios.<br /> *[mailto:coley...at...mitre.org Steve Christey](MITRE) por una importante revisión y la adición de los datos del MITRE CWE<br /> *[http://jeremiahgrossman.blogspot.com/ Jeremiah Grossman] ([http://www.whitehatsec.com/ WhiteHat Security]) por revisar y contribuir con información sobre el éxico (o falla) de la medidas de detección automatizadas.<br /> *[http://www.smithline.net/ Neil Smithline] ([http://www.bea.com/ BEA Systems]) por sus comentarios y producir la versión Wiki-<br /> *Sylvan von Stuppe por una revisión ejemplar.<br /> *Colin Wong, Nigel Evans y Andre Gironda por comentarios enviados por correo.<br /> <br /> == Conclusión ==<br /> <br /> {| border='1' cellpadding='2' <br /> |- <br /> |[[Top 10 2007-Secuencia de Comandos en Sitios Cruzados (XSS)|A1 - Secuencia de comandos en sitios cruzados (XSS)]]<br /> |Las fallas de XSS acurren cuando una aplicación toma la información proveida por el usuario y la envia a un navegador sin validarla primero o codificar el contenido. El XSS permite a los atacantes ejecurar scripts en el navegador de la víctima la cual puede secuestrar la sesión del usuario, modificación de sitios web, la posible introducción de gusanos, etc.<br /> |-<br /> <br /> |[[Top 10 2007-Fallas de Inyección|A2 - Inyección de código]]<br /> |La fallas de inyección, particularmente la inyección de SQL, son comunes en las aplicaciones Web. La inyección ocurre cuando los datos proveidos por el usuario son enviados a un interprete como parte de un comando o petición. Los datos hostiles del atacante engañan al interprete a ejecutar comandos no intencionados o cambiar los datos.<br /> |-<br /> <br /> |[[Top 10 2007-Ejecución de Ficheros Malintencionados|A3 - Ejecución maliciosa de archivos]]<br /> |El código vulnerable a inclusión remota de archivos permite a los atacantes incluir código y datos hostiles, resultando en ataques devastadores, como secuestro total del servidor. Los ataques de ejecución maliciosa de archivos afectan a PHP, XML y cualquier marco de trabajo que soporte el manejo de nombres de archivos o permita la interacción con los usuarios mediante el intercambio de archivos.<br /> |-<br /> <br /> |[[Top 10 2007-Referencia Insegura y Directa a Objetos|A4 - Referencia directa e insegura a objetos]]<br /> |Una referencia directa e insegura a objetos ocurre cuando un desarrollador expone una referencia a una implementación interna de un objeto como unn archivo, un directorio, un registro de BD o una llave, en forma de parámetro de URL o de una forma. Los atacantes pueden manipular esas referencias para acceder a otros objetos sin tener autorización<br /> |-<br /> <br /> |[[Top 10 2007-Vulnerabilidades de Falsificación de Petición en Sitios Cruzados (CSRF)|A5 - Falsificación de petición en sitios crusados (CSRF)]]<br /> |A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.<br /> <br /> |-<br /> <br /> |[[Top 10 2007-Revelación de Información y Gestión Incorrecta de Errores|A6 - Revelación de Información y Gestión Incorrecta de Errores]]<br /> |Las aplicaciones pueden (sin intención) revelar información sobre su configuración, funcionalidad interna o violar la privacidad a travez de una variedad de problemas de la aplicación. Los atacantes usan estas debilidades para robar información delicada o conducir ataques mas serios. <br /> |-<br /> <br /> |[[Top 10 2007-Autenticación y Gestión de Sesiones Disfuncional|A7 - Autentificación y gestión de sesiones disfuncional]]<br /> |Las credenciales de las cuenta y testigos de sesión son frecuentemente protegidos inadecuadamente. Los atacantes roban contraseñas, llaves o testigos de autneticación para asumir la identidad de otros usuarios.<br /> |-<br /> <br /> |[[Top 10 2007-Almacenamiento Criptográfico Inseguro|A8 - Almacenamiento cirptográfico inseguro]]<br /> |Las aplicaciones Web raramente usan funciones criptográdicas apropiadamente para proteger información y credenciales. Los atacantes usan la información mal protegida para hacer robos de identidad y otros crimenes, como fraude con tarjetas de crédito.<br /> |-<br /> <br /> |[[Top 10 2007-Comunicaciones inseguras|A9 - Comunicación Insegura]]<br /> |Las aplicaciones frecuentement falla al cifrar el tráfico de red cuando es necesario proteger comunicaciones delicadas.<br /> |-<br /> <br /> |[[Top 10 2007-Falla de restricción de acceso a URL|A10 - Falla de restricción de acceso a URL]]<br /> |Frecuentemente, una aplicacion solo protege funcionalidad delicada evitando mostrar la ligas o URLs a usuarios no autorizados. Los atacantes pueden usar esta debilidad para acceder y realizar operaciones no autorizadas al acceder a esas URLs directamente.<br /> |}<br /> '''&lt;center&gt;Tabla 1: La 10 mayores vulnerabilidades de OWASP 2007&lt;/center&gt;'''<br /> <br /> <br /> Hay muchas páginas en este documento que no están dedicadas a vulnerabilidades en específico y por lo tanto no están listadas en la tabla. Aqui hay una lista de ellas.<br /> <br /> {| border='1' cellpadding='2' <br /> |- <br /> |[[Top 10 2007]]<br /> |Ademas de proveed una presentación, y un marcador de la sección de &quot;conclusiones&quot; (esto puede hacerse arrastrando [https://www.owasp.org/index.php/Top_10_2007#Summary esta liga] a sus favoritos) nos da acceso rápido a el documento completo.<br /> |-<br /> |[[Top 10 2007-Metodología]]<br /> |Una descripción de la metodología usada para selecionar las vulnerabilidades para este documento.<br /> |-<br /> |[[Top 10 2007-¿A dondé sigo Ahora?]]<br /> |Algunas sugerencias sobre como proceder una ves que ha leído este documento.<br /> |-<br /> |[[Top 10 2007-Referencias]]<br /> |Recomendaciones para lectura posterior.<br /> |}<br /> '''&lt;center&gt;Tabla 1a: Paginas en el documento de la ''lista de las 10 mayores 2007'' que no son la lista de vulnerabilidades mencionadas arriba.&lt;/center&gt;'''<br /> <br /> ==Una nota sobre las diferentes versiones==<br /> Mientras que la única versión oficial de la ''lista de las 10 mayores vulnerabilidades de OWASP 2007'' es la version en PDF y en inglés, OWASP ah puesto a su disposición este Wiki que inicialmente contenia el mismo contenido que el PDF. Pero OWASP espera que cambien con su ayuda. OWASP promueve el envolvimiento de la comunidad y quiere su ayuda para hacer la versión Wiki mejor que nunca. Para ayudar a esto han creado un pequeño [[Editing:Top_10_2007|tutorial]] para iniciarlo en este proceso.<br /> <br /> ==Versiones para bajar==<br /> Puede bajar la lista 2007 (versión final) aqui:<br /> <br /> * [http://www.owasp.org/images/e/e8/OWASP_Top_10_2007.pdf (PDF, 930 kb)]<br /> &lt;!--* [http://www.owasp.org/images/2/24/OWASP_Top_10_2007.doc (Word, 514 kb)]--&gt;<br /> <br /> * [https://www.owasp.org/images/a/ae/OWASP_Top_10_2007_Spanish.pdf (Español PDF, 488kb)]<br /> <br /> * [https://www.owasp.org/images/c/ce/OWASP_Top_10_2007_-_French.pdf (Francés PDF, 455 kb)]<br /> <br /> * [http://www.metasecurity.org/owasp/OWASP_Top_10_2007_Korean.pdf (Koreano PDF, 768 kb)]<br /> <br /> * [http://csirt.ulakbim.gov.tr/dokumanlar/Ceviri_OWASP_ilk10_2007.pdf (Turco PDF, 718 kb)]<br /> <br /> * [http://www.owasp.org/images/4/42/OWASP_TOP_10_2007_PT-BR.pdf (Portuguese Brasileño PDF, 329 kb)]<br /> <br /> * [https://www.owasp.org/images/8/89/OWASP_Top_10_2007_for_JEE.pdf OWASP Top 10 para la versión empresarial de Java (PDF, 630 kb)]<br /> <br /> * Le gustaría tener esta versión en otro idioma? podriamos usar su ayuda para traducirla. Contacte a Andrew van der Stock (vanderaj ...(@)... owasp.org) para ayudarnos a traducir la lista de las 10 mayores a otro idioma.<br /> <br /> {{Top_10_2007:BottomTemplate|usenext=NextLink|next=-Metodología|useprev=Nothing|usemain=Nothing}}</div>

Jorge Correa https://wiki.owasp.org/index.php?title=Diez_Mayores_2007&diff=76478 2010-01-18T19:38:23Z

<p>Jorge Correa: </p> <hr /> <div>{{Top_10_2007:TopTemplate|usenext=NextLink|next=-Metodología|useprev=Nothing|usemain=Nothing}}<br /> <br /> ==Presentación==<br /> <br /> Bienvenidos a la lista de las 10 mayores vulnerabilidades de OWASP 2007! Esta edición, totalmente reescrita lista las vulnerabilidades más serias en aplicaciones web, discute como protegerse de ellas y provee ligas a mas información. '''La lista de las 10 mayores vulnerabilidades de OWASP ha sido traducida al Español. [https://www.owasp.org/images/a/ae/OWASP_Top_10_2007_Spanish.pdf De clic aquí] para la traducción al español!'''<br /> <br /> La lista de las 10 mayores de OWASP para la versión empresarial de Java esta disponible para bajarla [https://www.owasp.org/images/8/89/OWASP_Top_10_2007_for_JEE.pdf aqui]<br /> <br /> == Objetivo ==<br /> <br /> '''El objetivo principal de la lista de las 10 de OWASP es formar desarrolladores, diseñadores, arquitectos y organizaciones''' sobre las consecuencias de las vulnerabilidades más comunes en aplicaciones web. Las lista provee métodos básicos para protegerse contra estas vulnerabilidades - un gran inicio para su programa de codificación segura.<br /> <br /> '''La seguridad no es un evento de una sola vez'''. No es suficiente asegurar su código solo una vez. Para 2008, esta lista cambiará y sin cambiar una línea de el código de su aplicación, puede ser vulnerable. Por favor revise el consejo en [[Top_10_2007-Where to Go From Here|Top 10 2007-¿A dondé sigo Ahora?]] para mas información.<br /> <br /> '''Una iniciativa de codificación segura debe lidiar con todas las etapas de desarrollo del programa'''. Las aplicaciones Web seguras '''''solo''''' es posible cuando un SDLC seguro es usado. Los programas seguros desde el inicio por su diseño y desarrollo. Hay al menos 300 problemas que afectan la seguridad en general de una aplicación Web. Estos mas de 300 problemas están detallados en la [http://www.owasp.org/index.php/OWASP_Guide_Project Guía de OWASP], la cua es una lectura escencial para cualquiera que desarolle aplicaciones Web en la actualidad.<br /> <br /> '''Este documento es el principalmente un documento educativo, no un standard'''. Por favor no adopte este documento como una política o estándar sin [mailto:owasp@owasp.org hablar con nosotros] primero! Si necesita una política o estandar de codificación segura, OWASP tiene proyectos de políticas y estándares de seguridad que están en progreso. Por favor considere unirse o asistir financieramente estos esfuerzos.<br /> <br /> == Retroalimentación ==<br /> <br /> {| <br /> |-<br /> <br /> |Agradecemos a [http://www.mitre.org/ MITRE] por hacer ''La distribución de tipos de vulnerabilidades en el [http://cve.mitre.org/ CVE]'' disponibles libremente para su uso. El proyecto de la lista de las 10 mayores esta dirijida y patrocinada por [http://www.aspectsecurity.com https://www.owasp.org/images/d/d1/Aspect_logo.gif].<br /> |}<br /> <br /> Líder de proyecto: Andrew van der Stock (Director ejecutivo, Fundación OWASP)<br /> Co-autores: Jeff Williams (Presidencia, Fundación OWASP), Dave Wichers (Presidencia de conferencia, Fundación OWASP)<br /> <br /> Queremos agradecer a los revisores:<br /> <br /> *Raoul Endres por ayudar a echar a andar la lista de nuevo y por sus valiosos comentarios.<br /> *[mailto:coley...at...mitre.org Steve Christey](MITRE) por una importante revisión y la adición de los datos del MITRE CWE<br /> *[http://jeremiahgrossman.blogspot.com/ Jeremiah Grossman] ([http://www.whitehatsec.com/ WhiteHat Security]) por revisar y contribuir con información sobre el éxico (o falla) de la medidas de detección automatizadas.<br /> *[http://www.smithline.net/ Neil Smithline] ([http://www.bea.com/ BEA Systems]) por sus comentarios y producir la versión Wiki-<br /> *Sylvan von Stuppe por una revisión ejemplar.<br /> *Colin Wong, Nigel Evans y Andre Gironda por comentarios enviados por correo.<br /> <br /> == Conclusión ==<br /> <br /> {| border='1' cellpadding='2' <br /> |- <br /> |[[Top 10 2007-Secuencia de Comandos en Sitios Cruzados (XSS)|A1 - Secuencia de comandos en sitios cruzados (XSS)]]<br /> |Las fallas de XSS acurren cuando una aplicación toma la información proveida por el usuario y la envia a un navegador sin validarla primero o codificar el contenido. El XSS permite a los atacantes ejecurar scripts en el navegador de la víctima la cual puede secuestrar la sesión del usuario, modificación de sitios web, la posible introducción de gusanos, etc.<br /> |-<br /> <br /> |[[Top 10 2007-Fallas de Inyección|A2 - Inyección de código]]<br /> |La fallas de inyección, particularmente la inyección de SQL, son comunes en las aplicaciones Web. La inyección ocurre cuando los datos proveidos por el usuario son enviados a un interprete como parte de un comando o petición. Los datos hostiles del atacante engañan al interprete a ejecutar comandos no intencionados o cambiar los datos.<br /> |-<br /> <br /> |[[Top 10 2007-Ejecución de Ficheros Malintencionados|A3 - Ejecución maliciosa de archivos]]<br /> |El código vulnerable a inclusión remota de archivos permite a los atacantes incluir código y datos hostiles, resultando en ataques devastadores, como secuestro total del servidor. Los ataques de ejecución maliciosa de archivos afectan a PHP, XML y cualquier marco de trabajo que acepte nombres de archivos o archivos desde los usuarios.<br /> |-<br /> <br /> |[[Top 10 2007-Referencia Insegura y Directa a Objetos|A4 - Referencia directa e insegura a objetos]]<br /> |Una referencia directa e insegura a objetos ocurre cuando un desarrollador expone una referencia a una implementación interna de un objeto como unn archivo, un directorio, un registro de BD o una llave, en forma de parámetro de URL o de una forma. Los atacantes pueden manipular esas referencias para acceder a otros objetos sin tener autorización<br /> |-<br /> <br /> |[[Top 10 2007-Vulnerabilidades de Falsificación de Petición en Sitios Cruzados (CSRF)|A5 - Falsificación de petición en sitios crusados (CSRF)]]<br /> |A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.<br /> <br /> |-<br /> <br /> |[[Top 10 2007-Revelación de Información y Gestión Incorrecta de Errores|A6 - Revelación de Información y Gestión Incorrecta de Errores]]<br /> |Las aplicaciones pueden (sin intención) revelar información sobre su configuración, funcionalidad interna o violar la privacidad a travez de una variedad de problemas de la aplicación. Los atacantes usan estas debilidades para robar información delicada o conducir ataques mas serios. <br /> |-<br /> <br /> |[[Top 10 2007-Autenticación y Gestión de Sesiones Disfuncional|A7 - Autentificación y gestión de sesiones disfuncional]]<br /> |Las credenciales de las cuenta y testigos de sesión son frecuentemente protegidos inadecuadamente. Los atacantes roban contraseñas, llaves o testigos de autneticación para asumir la identidad de otros usuarios.<br /> |-<br /> <br /> |[[Top 10 2007-Almacenamiento Criptográfico Inseguro|A8 - Almacenamiento cirptográfico inseguro]]<br /> |Las aplicaciones Web raramente usan funciones criptográdicas apropiadamente para proteger información y credenciales. Los atacantes usan la información mal protegida para hacer robos de identidad y otros crimenes, como fraude con tarjetas de crédito.<br /> |-<br /> <br /> |[[Top 10 2007-Comunicaciones inseguras|A9 - Comunicación Insegura]]<br /> |Las aplicaciones frecuentement falla al cifrar el tráfico de red cuando es necesario proteger comunicaciones delicadas.<br /> |-<br /> <br /> |[[Top 10 2007-Falla de restricción de acceso a URL|A10 - Falla de restricción de acceso a URL]]<br /> |Frecuentemente, una aplicacion solo protege funcionalidad delicada evitando mostrar la ligas o URLs a usuarios no autorizados. Los atacantes pueden usar esta debilidad para acceder y realizar operaciones no autorizadas al acceder a esas URLs directamente.<br /> |}<br /> '''&lt;center&gt;Tabla 1: La 10 mayores vulnerabilidades de OWASP 2007&lt;/center&gt;'''<br /> <br /> <br /> Hay muchas páginas en este documento que no están dedicadas a vulnerabilidades en específico y por lo tanto no están listadas en la tabla. Aqui hay una lista de ellas.<br /> <br /> {| border='1' cellpadding='2' <br /> |- <br /> |[[Top 10 2007]]<br /> |Ademas de proveed una presentación, y un marcador de la sección de &quot;conclusiones&quot; (esto puede hacerse arrastrando [https://www.owasp.org/index.php/Top_10_2007#Summary esta liga] a sus favoritos) nos da acceso rápido a el documento completo.<br /> |-<br /> |[[Top 10 2007-Metodología]]<br /> |Una descripción de la metodología usada para selecionar las vulnerabilidades para este documento.<br /> |-<br /> |[[Top 10 2007-¿A dondé sigo Ahora?]]<br /> |Algunas sugerencias sobre como proceder una ves que ha leído este documento.<br /> |-<br /> |[[Top 10 2007-Referencias]]<br /> |Recomendaciones para lectura posterior.<br /> |}<br /> '''&lt;center&gt;Tabla 1a: Paginas en el documento de la ''lista de las 10 mayores 2007'' que no son la lista de vulnerabilidades mencionadas arriba.&lt;/center&gt;'''<br /> <br /> ==Una nota sobre las diferentes versiones==<br /> Mientras que la única versión oficial de la ''lista de las 10 mayores vulnerabilidades de OWASP 2007'' es la version en PDF y en inglés, OWASP ah puesto a su disposición este Wiki que inicialmente contenia el mismo contenido que el PDF. Pero OWASP espera que cambien con su ayuda. OWASP promueve el envolvimiento de la comunidad y quiere su ayuda para hacer la versión Wiki mejor que nunca. Para ayudar a esto han creado un pequeño [[Editing:Top_10_2007|tutorial]] para iniciarlo en este proceso.<br /> <br /> ==Versiones para bajar==<br /> Puede bajar la lista 2007 (versión final) aqui:<br /> <br /> * [http://www.owasp.org/images/e/e8/OWASP_Top_10_2007.pdf (PDF, 930 kb)]<br /> &lt;!--* [http://www.owasp.org/images/2/24/OWASP_Top_10_2007.doc (Word, 514 kb)]--&gt;<br /> <br /> * [https://www.owasp.org/images/a/ae/OWASP_Top_10_2007_Spanish.pdf (Español PDF, 488kb)]<br /> <br /> * [https://www.owasp.org/images/c/ce/OWASP_Top_10_2007_-_French.pdf (Francés PDF, 455 kb)]<br /> <br /> * [http://www.metasecurity.org/owasp/OWASP_Top_10_2007_Korean.pdf (Koreano PDF, 768 kb)]<br /> <br /> * [http://csirt.ulakbim.gov.tr/dokumanlar/Ceviri_OWASP_ilk10_2007.pdf (Turco PDF, 718 kb)]<br /> <br /> * [http://www.owasp.org/images/4/42/OWASP_TOP_10_2007_PT-BR.pdf (Portuguese Brasileño PDF, 329 kb)]<br /> <br /> * [https://www.owasp.org/images/8/89/OWASP_Top_10_2007_for_JEE.pdf OWASP Top 10 para la versión empresarial de Java (PDF, 630 kb)]<br /> <br /> * Le gustaría tener esta versión en otro idioma? podriamos usar su ayuda para traducirla. Contacte a Andrew van der Stock (vanderaj ...(@)... owasp.org) para ayudarnos a traducir la lista de las 10 mayores a otro idioma.<br /> <br /> {{Top_10_2007:BottomTemplate|usenext=NextLink|next=-Metodología|useprev=Nothing|usemain=Nothing}}</div>

Jorge Correa https://wiki.owasp.org/index.php?title=Diez_Mayores_2007&diff=76476 2010-01-18T19:32:55Z

<p>Jorge Correa: /* Conclusión */</p> <hr /> <div>{{Top_10_2007:TopTemplate|usenext=NextLink|next=-Metodología|useprev=Nothing|usemain=Nothing}}<br /> <br /> ==Presentación==<br /> <br /> Bienvenidos a la lista de las 10 mayores vulnerabilidades de OWASP 2007! Esta edición, totalmente reescrita lista las vulnerabilidades más serias en aplicaciones web, discute como protegerse de ellas y provee ligas a mas información. '''La lista de las 10 mayores vulnerabilidades de OWASP ha sido traducida al Español. [https://www.owasp.org/images/a/ae/OWASP_Top_10_2007_Spanish.pdf De clic aquí] para la traducción al español!'''<br /> <br /> La lista de las 10 mayores de OWASP para la versión empresarial de Java esta disponible para bajarla [https://www.owasp.org/images/8/89/OWASP_Top_10_2007_for_JEE.pdf aqui]<br /> <br /> == Objetivo ==<br /> <br /> '''El objetivo principal de la lista de las 10 de OWASP es formar desarrolladores, diseñadores, arquitectos y organizaciones''' sobre las consecuencias de las vulnerabilidades más comunes en aplicaciones web. Las lista provee métodos básicos para protegerse contra estas vulnerabilidades - un gran inicio para su programa de codificación segura.<br /> <br /> '''La seguridad no es un evento de una sola vez'''. No es suficiente asegurar su código solo una vez. Para 2008, esta lista cambiará y sin cambiar una línea de el código de su aplicación, puede ser vulnerable. Por favor revise el consejo en [[Top_10_2007-Where to Go From Here|Top 10 2007-¿A dondé sigo Ahora?]] para mas información.<br /> <br /> '''Una iniciativa de codificación segura debe lidiar con todas las etapas de desarrollo del programa'''. Las aplicaciones Web seguras '''''solo''''' es posible cuando un SDLC seguro es usado. Los programas seguros desde el inicio por su diseño y desarrollo. Hay al menos 300 problemas que afectan la seguridad en general de una aplicación Web. Estos mas de 300 problemas están detallados en la [http://www.owasp.org/index.php/OWASP_Guide_Project Guía de OWASP], la cua es una lectura escencial para cualquiera que desarolle aplicaciones Web en la actualidad.<br /> <br /> '''Este documento es el principalmente un documento educativo, no un standard'''. Por favor no adopte este documento como una política o estándar sin [mailto:owasp@owasp.org hablar con nosotros] primero! Si necesita una política o estandar de codificación segura, OWASP tiene proyectos de políticas y estándares de seguridad que están en progreso. Por favor considere unirse o asistir financieramente estos esfuerzos.<br /> <br /> == Retroalimentación ==<br /> <br /> {| <br /> |-<br /> <br /> |Agradecemos a [http://www.mitre.org/ MITRE] por hacer ''La distribución de tipos de vulnerabilidades en el [http://cve.mitre.org/ CVE]'' disponibles libremente para su uso. El proyecto de la lista de las 10 mayores esta dirijida y patrocinada por [http://www.aspectsecurity.com https://www.owasp.org/images/d/d1/Aspect_logo.gif].<br /> |}<br /> <br /> Líder de proyecto: Andrew van der Stock (Director ejecutivo, Fundación OWASP)<br /> Co-autores: Jeff Williams (Presidencia, Fundación OWASP), Dave Wichers (Presidencia de conferencia, Fundación OWASP)<br /> <br /> Queremos agradecer a los revisores:<br /> <br /> *Raoul Endres por ayudar a echar a andar la lista de nuevo y por sus valiosos comentarios.<br /> *[mailto:coley...at...mitre.org Steve Christey](MITRE) por una importante revisión y la adición de los datos del MITRE CWE<br /> *[http://jeremiahgrossman.blogspot.com/ Jeremiah Grossman] ([http://www.whitehatsec.com/ WhiteHat Security]) por revisar y contribuir con información sobre el éxico (o falla) de la medidas de detección automatizadas.<br /> *[http://www.smithline.net/ Neil Smithline] ([http://www.bea.com/ BEA Systems]) por sus comentarios y producir la versión Wiki-<br /> *Sylvan von Stuppe por una revisión ejemplar.<br /> *Colin Wong, Nigel Evans y Andre Gironda por comentarios enviados por correo.<br /> <br /> == Conclusión ==<br /> <br /> {| border='1' cellpadding='2' <br /> |- <br /> |[[Top 10 2007-Secuencia de Comandos en Sitios Cruzados (XSS)|A1 - Secuencia de comandos en sitios cruzados (XSS)]]<br /> |Las fallas de XSS acurren cuando una aplicación toma la información proveida por el usuario y la envia a un navegador sin validarla primero o codificar el contenido. El XSS permite a los atacantes ejecurar scripts en el navegador de la víctima la cual puede secuestrar la sesión del usuario, modificación de sitios web, la posible introducción de gusanos, etc.<br /> |-<br /> <br /> |[[Top 10 2007-Fallas de Inyección|A2 - Inyección de código SQL]]<br /> |La fallas de inyección, particularmente la inyección de SQL, son comunes en las aplicaciones Web. La inyección ocurre cuando los datos proveidos por el usuario son enviados a un interprete como parte de un comando o petición. Los datos hostiles del atacante engañan al interprete a ejecutar comandos no intencionados o cambiar los datos.<br /> |-<br /> <br /> |[[Top 10 2007-Ejecución de Ficheros Malintencionados|A3 - Ejecución maliciosa de archivos]]<br /> |El código vulnerable a inclusión remota de archivos permite a los atacantes incluir código y datos hostiles, resultando en ataques devastadores, como secuestro total del servidor. Los ataques de ejecución maliciosa de archivos afectan a PHP, XML y cualquier marco de trabajo que acepte nombres de archivos o archivos desde los usuarios.<br /> |-<br /> <br /> |[[Top 10 2007-Referencia Insegura y Directa a Objetos|A4 - Referencia directa e insegura a objetos]]<br /> |Una referencia directa e insegura a objetos ocurre cuando un desarrollador expone una referencia a una implementación interna de un objeto como unn archivo, un directorio, un registro de BD o una llave, en forma de parámetro de URL o de una forma. Los atacantes pueden manipular esas referencias para acceder a otros objetos sin tener autorización<br /> |-<br /> <br /> |[[Top 10 2007-Vulnerabilidades de Falsificación de Petición en Sitios Cruzados (CSRF)|A5 - Falsificación de petición en sitios crusados (CSRF)]]<br /> |A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.<br /> <br /> |-<br /> <br /> |[[Top 10 2007-Revelación de Información y Gestión Incorrecta de Errores|A6 - Revelación de Información y Gestión Incorrecta de Errores]]<br /> |Las aplicaciones pueden (sin intención) revelar información sobre su configuración, funcionalidad interna o violar la privacidad a travez de una variedad de problemas de la aplicación. Los atacantes usan estas debilidades para robar información delicada o conducir ataques mas serios. <br /> |-<br /> <br /> |[[Top 10 2007-Autenticación y Gestión de Sesiones Disfuncional|A7 - Autentificación y gestión de sesiones disfuncional]]<br /> |Las credenciales de las cuenta y testigos de sesión son frecuentemente protegidos inadecuadamente. Los atacantes roban contraseñas, llaves o testigos de autneticación para asumir la identidad de otros usuarios.<br /> |-<br /> <br /> |[[Top 10 2007-Almacenamiento Criptográfico Inseguro|A8 - Almacenamiento cirptográfico inseguro]]<br /> |Las aplicaciones Web raramente usan funciones criptográdicas apropiadamente para proteger información y credenciales. Los atacantes usan la información mal protegida para hacer robos de identidad y otros crimenes, como fraude con tarjetas de crédito.<br /> |-<br /> <br /> |[[Top 10 2007-Comunicaciones inseguras|A9 - Comunicación Insegura]]<br /> |Las aplicaciones frecuentement falla al cifrar el tráfico de red cuando es necesario proteger comunicaciones delicadas.<br /> |-<br /> <br /> |[[Top 10 2007-Falla de restricción de acceso a URL|A10 - Falla de restricción de acceso a URL]]<br /> |Frecuentemente, una aplicacion solo protege funcionalidad delicada evitando mostrar la ligas o URLs a usuarios no autorizados. Los atacantes pueden usar esta debilidad para acceder y realizar operaciones no autorizadas al acceder a esas URLs directamente.<br /> |}<br /> '''&lt;center&gt;Tabla 1: La 10 mayores vulnerabilidades de OWASP 2007&lt;/center&gt;'''<br /> <br /> <br /> Hay muchas páginas en este documento que no están dedicadas a vulnerabilidades en específico y por lo tanto no están listadas en la tabla. Aqui hay una lista de ellas.<br /> <br /> {| border='1' cellpadding='2' <br /> |- <br /> |[[Top 10 2007]]<br /> |Ademas de proveed una presentación, y un marcador de la sección de &quot;conclusiones&quot; (esto puede hacerse arrastrando [https://www.owasp.org/index.php/Top_10_2007#Summary esta liga] a sus favoritos) nos da acceso rápido a el documento completo.<br /> |-<br /> |[[Top 10 2007-Metodología]]<br /> |Una descripción de la metodología usada para selecionar las vulnerabilidades para este documento.<br /> |-<br /> |[[Top 10 2007-¿A dondé sigo Ahora?]]<br /> |Algunas sugerencias sobre como proceder una ves que ha leído este documento.<br /> |-<br /> |[[Top 10 2007-Referencias]]<br /> |Recomendaciones para lectura posterior.<br /> |}<br /> '''&lt;center&gt;Tabla 1a: Paginas en el documento de la ''lista de las 10 mayores 2007'' que no son la lista de vulnerabilidades mencionadas arriba.&lt;/center&gt;'''<br /> <br /> ==Una nota sobre las diferentes versiones==<br /> Mientras que la única versión oficial de la ''lista de las 10 mayores vulnerabilidades de OWASP 2007'' es la version en PDF y en inglés, OWASP ah puesto a su disposición este Wiki que inicialmente contenia el mismo contenido que el PDF. Pero OWASP espera que cambien con su ayuda. OWASP promueve el envolvimiento de la comunidad y quiere su ayuda para hacer la versión Wiki mejor que nunca. Para ayudar a esto han creado un pequeño [[Editing:Top_10_2007|tutorial]] para iniciarlo en este proceso.<br /> <br /> ==Versiones para bajar==<br /> Puede bajar la lista 2007 (versión final) aqui:<br /> <br /> * [http://www.owasp.org/images/e/e8/OWASP_Top_10_2007.pdf (PDF, 930 kb)]<br /> &lt;!--* [http://www.owasp.org/images/2/24/OWASP_Top_10_2007.doc (Word, 514 kb)]--&gt;<br /> <br /> * [https://www.owasp.org/images/a/ae/OWASP_Top_10_2007_Spanish.pdf (Español PDF, 488kb)]<br /> <br /> * [https://www.owasp.org/images/c/ce/OWASP_Top_10_2007_-_French.pdf (Francés PDF, 455 kb)]<br /> <br /> * [http://www.metasecurity.org/owasp/OWASP_Top_10_2007_Korean.pdf (Koreano PDF, 768 kb)]<br /> <br /> * [http://csirt.ulakbim.gov.tr/dokumanlar/Ceviri_OWASP_ilk10_2007.pdf (Turco PDF, 718 kb)]<br /> <br /> * [http://www.owasp.org/images/4/42/OWASP_TOP_10_2007_PT-BR.pdf (Portuguese Brasileño PDF, 329 kb)]<br /> <br /> * [https://www.owasp.org/images/8/89/OWASP_Top_10_2007_for_JEE.pdf OWASP Top 10 para la versión empresarial de Java (PDF, 630 kb)]<br /> <br /> * Le gustaría tener esta versión en otro idioma? podriamos usar su ayuda para traducirla. Contacte a Andrew van der Stock (vanderaj ...(@)... owasp.org) para ayudarnos a traducir la lista de las 10 mayores a otro idioma.<br /> <br /> {{Top_10_2007:BottomTemplate|usenext=NextLink|next=-Metodología|useprev=Nothing|usemain=Nothing}}</div>

Jorge Correa