The document outlines key application security risks identified by the Open Web Application Security Project (OWASP), emphasizing the importance of integrating security practices throughout the software development lifecycle. It discusses ten critical risks including injection flaws, broken authentication, and sensitive data exposure, along with recommendations for mitigating these threats. Additionally, it highlights the necessity of secure development practices, continuous education, and the implementation of security controls in order to protect both applications and user data effectively.

1. Overview for Web Developers
Benjamin Floyd
@dataplex

2. Gold
Silver
Bronze

3. First a Story…

4.  Passionate about security
 .NET Developer
 Senior Consultant for Headspring in Houston

5. The Open Web Application Security Project
(OWASP) is an open community dedicated to
enabling organizations to develop, purchase, and
maintain applications that can be trusted.

6.  The goal is to raise awareness about
application security
 Identifying some of the most critical risks
facing organizations
 Referenced by standards
 PCI DSS
 DISA, FTC, MITRE
 Released in 2003, 04, 07, 10, 13

7.  Help your organization get started in
application security
 Secure your applications without being an
expert

8. $80 Million in HELOC
FraudDave and Busters,
TJ Maxx, Heartland
45.6 Million CC
Stolen
Texas comptroller’s
office data breach
exposes 3.5 million
teachers’ and
employees’ Social
Security numbers

9.  Your Project…
 Address security threats one at a time
 Automate the tools available at OWASP, M$, etc
 Your Organization
 Discuss regulations and penalties (risks to ROI)
 Better coding practices means better code
 Your customers
 They should be demanding this already! And they
will…

10. Let’s Dig In…

11.  A1 Injection
 A2 Broken Authentication and Session
Management
 Was formerly 2010-A3
 A3 Cross-Site Scripting (XSS)
 was formerly 2010-A2
 A4 Insecure Direct Object References
 A5 Security Misconfiguration
 was formerly 2010-A6
 A6 Sensitive Data Exposure
 2010-A7 Insecure Cryptographic Storage and 2010-A9
Insufficient Transport Layer Protection were merged to
form 2013-A6

12.  A7 Missing Function Level Access Control
 Renamed/broadened from 2010-A8 Failure to
Restrict URL Access
 A8 Cross-Site Request Forgery (CSRF)
 Was formerly 2010-A5
 A9 Using Components with Known
Vulnerabilities
 New but was part of 2010-A6 – Security
Misconfiguration
 A10 Unvalidated Redirects and Forwards

13. Injection flaws, such as SQL, OS, and LDAP
injection occur when untrusted data is sent to an
interpreter as part of a command or query.
The attacker’s hostile data can trick the interpreter
into executing unintended commands or accessing
data without proper authorization.

14.  Querystrings…
 Str sql = “SELECT * FROM ImportantTable WHERE
Id =“ + Request.Querystring[“id”];
 Forms…
 Sql = “…” + model.UserInput + “;”;
 Cookies…
 Anywhere users can supply input that is
interpreted!

15.  Keep untrusted data separate from commands
and queries:
 Parameterized SQL (99%)
 Command Injection (file paths, etc)
 XML Injection (XPath, XQuery, etc)
 LDAP (Active Directory)

16. Application functions related to authentication and
session management are often not implemented
correctly, allowing attackers to compromise
passwords, keys, or session tokens, or to exploit
other implementation flaws to assume other users’
identities.

17.  Are session management assets like user credentials and
session IDs properly protected? You may be vulnerable if:
 User authentication credentials aren’t protected when stored using
hashing or encryption. See A6.
 Credentials can be guessed or overwritten through weak account
management functions (e.g., account creation, change password,
recover password, weak session IDs).
 Session IDs are exposed in the URL (e.g., URL rewriting).
 Session IDs are vulnerable to session fixation attacks.
 Session IDs don’t timeout, or user sessions or authentication
tokens, particularly single sign-on (SSO) tokens, aren’t properly
invalidated during logout.
 Session IDs aren’t rotated after successful login.
 Passwords, session IDs, and other credentials are sent over
unencrypted connections. See A6.

18.  Prevent XSS (A3)
 Use framework provided authentication and
session management APIs
 .NET Membership Providers
 OWASP ESAPI Authenticator

19.  Again…REALLY?!?!?!
“…if you do not ensure that all user supplied input is
properly escaped, or you do not verify it to be safe via
input validation, before including that input in the
output page. Without proper output escaping or
validation, such input will be treated as active content
in the browser.”
“If Ajax is being used to dynamically update the page,
are you using safe JavaScript APIs? For unsafe
JavaScript APIs, encoding or validation must also be
used.”

20.  Validate your input!!!
 Properly encode your output!!!
 .NET
 Use Razor View Engine – encoding by default!
 ASP.NET View Engine – Use <%: %> not <%= %>
 Microsoft AntiXSS Library
 Rich content – OWASP AntiSamy

21. A direct object reference occurs when a developer
exposes a reference to an internal implementation
object, such as a file, directory, or database key.
Without an access control check or other
protection, attackers can manipulate these
references to access unauthorized data.

22. Good security requires having a secure
configuration defined and deployed for the
application, frameworks, application server, web
server, database server, and platform.
Secure settings should be defined, implemented,
and maintained, as defaults are often insecure.
Additionally, software should be kept up to date.

23. Many web applications do not properly protect
sensitive data, such as credit cards, tax IDs, and
authentication credentials. Attackers may steal or
modify such weakly protected data to conduct
credit card fraud, identity theft, or other crimes.
Sensitive data deserves extra protection such as
encryption at rest or in transit, as well as special
precautions when exchanged with the browser.

24. Most web applications verify function level access
rights before making that functionality visible in
the UI. However, applications need to perform the
same access control checks on the server when
each function is accessed.
If requests are not verified, attackers will be able to
forge requests in order to access functionality
without proper authorization.

25. A CSRF attack forces a logged-on victim’s browser
to send a forged HTTP request, including the
victim’s session cookie and any other
automatically included authentication information,
to a vulnerable web application.
This allows the attacker to force the victim’s
browser to generate requests the vulnerable
application thinks are legitimate requests from the
victim.

26. Components, such as libraries, frameworks, and
other software modules, almost always run with
full privileges. If a vulnerable component is
exploited, such an attack can facilitate serious data
loss or server takeover.
Applications using components with known
vulnerabilities may undermine application
defenses and enable a range of possible attacks
and impacts.

27. Web applications frequently redirect and forward
users to other pages and websites, and use
untrusted data to determine the destination pages.
Without proper validation, attackers can redirect
victims to phishing or malware sites, or use
forwards to access unauthorized pages.

28. Where to go from here?

29.  Include security into your dev process
 Application Security Requirements
 Application Security Architecture
 Standard Security Controls
 Secure Development Lifecycle
 Application Security Education

30.  Get organized and talk with developers
 Code reviews
 Security Testing
 Penetration Testing
 Security Controls Automation

31.  Get Started…seriously…
 Risk Based Portfolio Approach
 Enable with a Strong Foundation
 Integrate Security into Existing Processes
 Provide Management Visibility

32. What Else?

33.  Cheat Sheets on all of the top 10 list
 Specific cheat sheets for specific languages or
frameworks
 Other related technology security issues
 Database
 Web server
 Etc…

34.  http://www.troyhunt.com/2011/12/free-
ebook-owasp-top-10-for-net.html
 Free Ebook – OWASP Top 10 for .NET
 Based on 2010 list

35. The Security Development Lifecycle (SDL) is a
software development process that helps
developers build more secure software and
address security compliance requirements while
reducing development cost.
 Take the top 10 and build these checks into
your process
 “Push left”

36. The end…

37. Please rate this talk!
http://spkr8.com/t/24751
Benjamin Floyd
dataplex@gmail.com
@dataplex
Skype: Dat4plex
http://www.CombatProgramming.com
Please rate this talk!