2. About Me
Chris Holwerda!
Architect and developer for 15+ years in the financial, money
codes, and credit card processing industry.
MasterCard
Enforcing PCI Compliance (Payment Card Industry)
blog: chrisholwerda.com
twitter: @cholwerda
email: therealchrisholwerda@gmail.com
SpeakerRate: http://speakerrate.com/chrisholwerda
!
3. Security In General
• Security is HARD
• There is no silver bullet
• Hackers will always have the upper hand
• Have an “everyone” is a hacker mentality
• Objective is to minimize risk and losses if breached
4. What is OWASP?
• Open Web Application Security Project
• Mission: To make software security visible so that organizations
worldwide can make informed decision about true software security
risks
• Open for anyone
• You can sign up to receive OWASP information updates
• You can attend meetings. They have chapters in a most of the
major cities, including Phoenix.
• Website has a lot of resources with examples in multiple
programming languages
6. OWASP Top 10 for 2013
• A1 – Injection
• A2 – Broken Authentication
& Session Management
• A3 – Cross-Site Scripting
(XSS)
• A4 – Insecure Direct Object
References
• A5 – Security
Misconfiguration
• A6 – Sensitive Data
Exposure
• A7 – Missing Function Level
Access Control
• A8 – Cross-Site Request
Forgery (CSRF)
• A9 – Using Components
with Known Vulnerabilities
• A10 – Un-validated
Redirects and Forwards
7. A1 - Injection
• Validate all input.
• Use white listing (valid chars) over black listing (invalid chars)
• Be careful with concatenations using any exposed values
• For SQL, use parameterized SQL queries
• Remember, it’s not just SQL
• Command line switch concatenations
• Other objects/apps that take parameters
8. A2 - Broken Authentication
and Session Management
• Make sure encryption of user’s password is “solid”.
• Make sure change/recover password process is “solid”
• Never email password – only allow reset
• Reset only using email address – do not confirm validity of address!
• One way hash preferred
• Don’t expose session Ids in the URL
• Security questions - don’t let user’s create their own
• Make sure authentication cookies are created/expired/timed out as expected
• Use Https
• XSS vulnerabilities can lead to sessions being stolen
9. A3 - Cross Site Scripting
(XSS)
• Escape all untrusted data
• Validate all input.
• Use white listing (valid chars) over black listing
(invalid chars)
• Mark all cookies as HttpOnly and Secure
• Use trusted anti-sanitation libraries
10. A4 - Insecure Direct Object
References
• Authorize the user for every request, verify access
to the item requested
• Use per user or session indirect object references
• Ie: Map grid row with a row Id that maps back to
the actual key in stored in session
11. A5 - Security
Misconfiguration
• Repeatable deployment process – preferably
automated – that is locked down
• Process for updating software and patches
• Run scans and audits for detecting
12. A6 - Sensitive Data
Exposure
• Encrypt/hash all sensitive data at rest and in transit
• Use standard algorithms and strong key/salt
• Ensure passwords are stored with algorithm
specifically designed for password protection
• Disable autocomplete on forms and disable
caching for pages that contain sensitive data
13. A7 - Missing Function Level
Access Control
• Have an easy to use common consistent
authorization module
• Deny all access by default
• Implement checks in business layer
• Ie: link on website hidden, but user could still enter
in URL and gain access = BAD
• Back to -> authorize every request
14. A8 - Cross Site Request
Forgery (CSRF)
• Include unpredictable token in each request – at a
minimum, unique per user session
• Preferred is by using a hidden field vs. added to
URL
• There are some tools in .NET to use
• Re-authenticate user or prove they are a user (ie:
use a captcha)
15. A9 - Using Components with
known vulnerabilities
• Have a process in place to update component
• Monitor the security of the components
• Govern component use
• Add security wrappers around component
16. A10 - Unvalidated Redirects
and Forwards
• Avoid using redirects and forwards
• Don’t involve user parameters in calculating
destination
• If destination parameters cannot be avoided
• Validate value and that the user is authorized
• Use mapping values instead of actual value
