DEVELOPING SECURE APPLICATIONS AND DEFENDING AGAINST ATTACKS Andy Steingruebl, Manager, Information Risk Management
AGENDA <ul><li>Introduction </li></ul><ul><li>Top Web Application Attacks </li></ul><ul><li>Secure Development Techniques ...
WHEN SECURITY FAILS
TYPICAL SECURITY MEASURES IN A BANK
AGENDA <ul><li>Introduction </li></ul><ul><li>Top Web Application Attacks </li></ul><ul><li>Secure Development Techniques ...
THE PROBLEM OF SECURITY <ul><li>Large and complex systems interact to make perfect security impossible. </li></ul><ul><li>...
A BRIEF HISTORY OF SECURITY ISSUES 1994 Amazon 1995 Yahoo! 1998 Google 2005 YouTube
OPEN WEB APPLICATION SECURITY PROJECT (OWASP) TOP 10 <ul><li>Cross Site Scripting (XSS) </li></ul><ul><li>Injection flaws ...
WEB APPLICATION SECURITY CONSORTIUM (WASC) THREAT CLASSIFICATION <ul><li>The threat classification is an effort to classif...
CROSS SITE SCRIPTING (XSS) <ul><li>What if  <iframe src=&quot;http://en.wikipedia.com&quot; height=&quot;1180&quot;  width...
CROSS SITE SCRIPTING (XSS) <ul><li>XSS Code allows an attacker to: </li></ul><ul><ul><li>Exploit the user’s trust for a we...
XSS MITIGATION <ul><li>Output filtering </li></ul><ul><ul><li>Encode fields to escape HTML in output (HTML entity encoding...
CROSS SITE REQUEST FORGERY (CSRF) <ul><li>Takes advantage of a website’s trust of a user </li></ul><ul><li>Example: A user...
CSRF MITIGATION <ul><li>Use CSRF tokens. </li></ul><ul><li>Tokens must be associated with the user’s session. </li></ul><u...
SQL INJECTION <ul><li>Flaw when SQL statements are formed by string concatenation </li></ul><ul><li>statement = &quot;SELE...
MITIGATING SQL INJECTION <ul><li>Validate all input parameters accepted by the web application. </li></ul><ul><li>Create S...
ATTACKING LOGIN FUNCTIONALITY <ul><li>Typical attacks against login functionality </li></ul><ul><ul><li>Username enumerati...
MITIGATING LOGIN ATTACKS <ul><li>Develop generic error messages. </li></ul><ul><li>Enforce account lockout after failed lo...
COMMON SHOPPING CART ATTACKS <ul><li>Price tampering </li></ul><ul><li>Fake referrer header attack </li></ul>
PRICE TAMPERING <ul><li>One of the oldest web attacks </li></ul><ul><li>Defense is fairly straightforward </li></ul><ul><l...
REFERER HEADER ATTACKS <ul><li>Do not rely on HTTP REFERER header for security decisions. </li></ul><ul><li>REFERER can be...
APPLICATION SECURITY TESTING <ul><li>The simplest application security testing tools are client-side proxies </li></ul><ul...
APPLICATION SECURITY TESTING (CONT’D) Tools help developers and testers debug HTTP/HTTPS traffic and help identify potenti...
AGENDA <ul><li>Introduction </li></ul><ul><li>Top Web Application Attacks </li></ul><ul><li>Secure Development Techniques ...
APPLICATION SECURITY AND SDLC <ul><li>“ 70% of security vulnerabilities exist at the application layer, not the network la...
SECURITY IN SDLC <ul><li>Ensure that both design and implementation security-related bugs  don’t get released into product...
WHY BEST PRACTICES? <ul><li>Why best practices? </li></ul><ul><ul><li>Can make code easier to read and less ambiguous </li...
COMPUTER EMERGENCY RESPONSE TEAM (CERT) SECURE CODING BEST PRACTICES <ul><li>Validate input. </li></ul><ul><li>Heed compil...
INPUT VALIDATION <ul><li>BELIEVE IN NOTHING!! </li></ul><ul><ul><li>Everything that comes from the user/browser is not to ...
MORE SECURITY BEST PRACTICES <ul><li>Don’t store passwords in the source code. </li></ul><ul><li>Don’t try to invent your ...
AGENDA <ul><li>Introduction </li></ul><ul><li>Top Web Application Attacks </li></ul><ul><li>Secure Development Techniques ...
SECURITY WITH PayPal PRODUCTS <ul><li>Always use HTTPS when talking to PayPal. </li></ul><ul><li>Always integrate with web...
CONCLUDING THOUGHTS <ul><li>Be careful about handling input to your application. </li></ul><ul><li>Stay current on securit...
MORE INFORMATION <ul><li>Websites </li></ul><ul><ul><li>The Open Web Application Security Project ( http://www.owasp.org )...
LEARN AND SHARE <ul><li>www.x.com </li></ul><ul><li>Twitter:  @paypalx </li></ul><ul><li>www.facebook.com/paypalx </li></u...
Upcoming SlideShare
Loading in...5
×

Developing Secure Applications and Defending Against Common Attacks

5,123
-1

Published on

Make sure you’re defending against the most common web security issues and attacks with this useful overview of software development best-practices. We'll go over the most common attacks against web applications and present real world advice for defending yourself against these types of attacks.

Published in: Technology
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,123
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

Developing Secure Applications and Defending Against Common Attacks

  1. 1. DEVELOPING SECURE APPLICATIONS AND DEFENDING AGAINST ATTACKS Andy Steingruebl, Manager, Information Risk Management
  2. 2. AGENDA <ul><li>Introduction </li></ul><ul><li>Top Web Application Attacks </li></ul><ul><li>Secure Development Techniques </li></ul><ul><li>Tips for Security with PayPal Products </li></ul>
  3. 3. WHEN SECURITY FAILS
  4. 4. TYPICAL SECURITY MEASURES IN A BANK
  5. 5. AGENDA <ul><li>Introduction </li></ul><ul><li>Top Web Application Attacks </li></ul><ul><li>Secure Development Techniques </li></ul><ul><li>Tips for Security with PayPal Products </li></ul>
  6. 6. THE PROBLEM OF SECURITY <ul><li>Large and complex systems interact to make perfect security impossible. </li></ul><ul><li>New vulnerabilities are discovered almost every day. </li></ul><ul><li>Authorized users misuse access. </li></ul>
  7. 7. A BRIEF HISTORY OF SECURITY ISSUES 1994 Amazon 1995 Yahoo! 1998 Google 2005 YouTube
  8. 8. OPEN WEB APPLICATION SECURITY PROJECT (OWASP) TOP 10 <ul><li>Cross Site Scripting (XSS) </li></ul><ul><li>Injection flaws </li></ul><ul><li>Malicious file execution </li></ul><ul><li>Insecure direct object reference </li></ul><ul><li>Cross Site Request Forgery (CSRF) </li></ul><ul><li>Information leakage and improper error handling </li></ul><ul><li>Broken authentication and session management </li></ul><ul><li>Insecure cryptographic storage </li></ul><ul><li>Insecure communications </li></ul><ul><li>Failure to restrict URL access </li></ul>Source: http://www.owasp.org/index.php/Top_10_2007
  9. 9. WEB APPLICATION SECURITY CONSORTIUM (WASC) THREAT CLASSIFICATION <ul><li>The threat classification is an effort to classify the weaknesses and attacks that can lead to the compromise of a website, its data, or its users. </li></ul>Found at http://www.webappsec.org/projects/threat/
  10. 10. CROSS SITE SCRIPTING (XSS) <ul><li>What if <iframe src=&quot;http://en.wikipedia.com&quot; height=&quot;1180&quot; width=&quot;100%&quot;></iframe> was somebody’s name? </li></ul>
  11. 11. CROSS SITE SCRIPTING (XSS) <ul><li>XSS Code allows an attacker to: </li></ul><ul><ul><li>Exploit the user’s trust for a web site </li></ul></ul><ul><ul><li>Make requests using victim’s credentials </li></ul></ul><ul><ul><li>Alter the website (phishing attacks) </li></ul></ul><ul><ul><li>Track user activity </li></ul></ul><ul><ul><li>Hijack a user’s session </li></ul></ul><ul><ul><li>Provide an attack vector used by web focused worms </li></ul></ul>
  12. 12. XSS MITIGATION <ul><li>Output filtering </li></ul><ul><ul><li>Encode fields to escape HTML in output (HTML entity encoding) </li></ul></ul><ul><ul><li>Use context-appropriate encoding </li></ul></ul><ul><li>Input validation </li></ul><ul><ul><li>Don’t trust user input </li></ul></ul><ul><ul><li>Validate using a white list </li></ul></ul><ul><li>Cookie security flags </li></ul><ul><ul><li>HTTP only </li></ul></ul><ul><ul><li>Secure (not an XSS protection, but still a good idea) </li></ul></ul>
  13. 13. CROSS SITE REQUEST FORGERY (CSRF) <ul><li>Takes advantage of a website’s trust of a user </li></ul><ul><li>Example: A user is sent an email with an image link. When they load the email, it tries to load an image. </li></ul><ul><ul><li><image src=“https://www.yourbank.com/ tranfer_money?to=attacker_account& amount=1000”> </li></ul></ul>
  14. 14. CSRF MITIGATION <ul><li>Use CSRF tokens. </li></ul><ul><li>Tokens must be associated with the user’s session. </li></ul><ul><li>The combination of cookie and token must be unique and received within a specific window of time. </li></ul><ul><ul><li>OR </li></ul></ul><ul><li>Require users to re-authenticate before performing sensitive transactions. </li></ul>
  15. 15. SQL INJECTION <ul><li>Flaw when SQL statements are formed by string concatenation </li></ul><ul><li>statement = &quot;SELECT * FROM users WHERE name = '&quot; + userName + &quot;'&quot;; </li></ul><ul><li>What if the user enters: &quot;' or 'x'='x&quot; ? </li></ul>Source: http://xkcd.com/327/
  16. 16. MITIGATING SQL INJECTION <ul><li>Validate all input parameters accepted by the web application. </li></ul><ul><li>Create SQL queries in a secure manner. </li></ul><ul><ul><li>Like PreparedStatement or CallableStatement </li></ul></ul><ul><li>Parameterized queries are not vulnerable to most types of SQL injection attacks. </li></ul>
  17. 17. ATTACKING LOGIN FUNCTIONALITY <ul><li>Typical attacks against login functionality </li></ul><ul><ul><li>Username enumeration </li></ul></ul><ul><ul><li>Password guessing </li></ul></ul><ul><ul><li>Brute-force attacks </li></ul></ul><ul><ul><li>Authentication mechanism attack </li></ul></ul><ul><ul><ul><li>For example, ‘Basic Web Server Authentication’ is really a Base64 encoded username/password passed in headers without encryption Authorization: Basic RG9udFVzZVRoaXNQYXNzd29yZA== </li></ul></ul></ul>
  18. 18. MITIGATING LOGIN ATTACKS <ul><li>Develop generic error messages. </li></ul><ul><li>Enforce account lockout after failed log in attempts. </li></ul><ul><li>Implement account lockout until reset. </li></ul><ul><li>Make sure account lockout triggers notification. </li></ul><ul><li>Implement server-side enforcement of password syntax and strength. </li></ul>
  19. 19. COMMON SHOPPING CART ATTACKS <ul><li>Price tampering </li></ul><ul><li>Fake referrer header attack </li></ul>
  20. 20. PRICE TAMPERING <ul><li>One of the oldest web attacks </li></ul><ul><li>Defense is fairly straightforward </li></ul><ul><li>Store price information in server-side state </li></ul><ul><li>Employ effective controls during shipping processes </li></ul><ul><li>Recommended PayPal Products include Website Payments Standard saved buttons and Express Checkout </li></ul>
  21. 21. REFERER HEADER ATTACKS <ul><li>Do not rely on HTTP REFERER header for security decisions. </li></ul><ul><li>REFERER can be tampered with by the end user. </li></ul><ul><li>For instant-fulfillment requirements, we strongly recommend PayPal Express Checkout. </li></ul><ul><li>If you use Website Payments Standard, make sure to confirm payments before delivering goods to the customer. </li></ul>
  22. 22. APPLICATION SECURITY TESTING <ul><li>The simplest application security testing tools are client-side proxies </li></ul><ul><ul><li>Burp </li></ul></ul><ul><ul><li>Paros </li></ul></ul><ul><ul><li>Fiddler </li></ul></ul><ul><ul><li>WebScarab </li></ul></ul><ul><li>Browser plug-ins can also help </li></ul><ul><ul><li>Tamper Data </li></ul></ul><ul><ul><li>HttpWatch </li></ul></ul><ul><li>Free, commercial tools exist to automate security testing </li></ul><ul><ul><li>AppScan </li></ul></ul><ul><ul><li>WebInspect </li></ul></ul>
  23. 23. APPLICATION SECURITY TESTING (CONT’D) Tools help developers and testers debug HTTP/HTTPS traffic and help identify potential vulnerabilities like XSS, CSRF, and so on.
  24. 24. AGENDA <ul><li>Introduction </li></ul><ul><li>Top Web Application Attacks </li></ul><ul><li>Secure Development Techniques </li></ul><ul><li>Tips for Security with PayPal Products </li></ul>
  25. 25. APPLICATION SECURITY AND SDLC <ul><li>“ 70% of security vulnerabilities exist at the application layer, not the network layer. The most damaging targeted attacks have focused on vulnerabilities in web applications and custom developed software.” </li></ul><ul><ul><li>Gartner </li></ul></ul><ul><li>“ The only people who can solve software security are the builders.” </li></ul><ul><li>Gary McGraw, “Building Secure Software” </li></ul><ul><li>“ The cost of removing an application security vulnerability during the design/development phase ranges from 30-60 times less than if removed during production.” </li></ul><ul><ul><li>NIST, IBM, and Gartner </li></ul></ul>Several standards and regulatory compliance requirements directly or indirectly mandate the need for application security controls - PCI DSS, ISO 17799/27001, SOX, GLBA, etc.
  26. 26. SECURITY IN SDLC <ul><li>Ensure that both design and implementation security-related bugs don’t get released into production. </li></ul>Security in SDLC
  27. 27. WHY BEST PRACTICES? <ul><li>Why best practices? </li></ul><ul><ul><li>Can make code easier to read and less ambiguous </li></ul></ul><ul><ul><li>Solves some problems </li></ul></ul><ul><ul><li>More robust in the face of change </li></ul></ul><ul><ul><li>Reduces the likelihood of common flaws </li></ul></ul><ul><ul><li>Dangerous areas are clearly marked </li></ul></ul><ul><li>Secure development can benefit from checklists </li></ul><ul><ul><li>Did I make sure to check for error conditions? </li></ul></ul><ul><ul><li>Did I make sure I avoided banned behaviors? </li></ul></ul><ul><ul><li>Did I make sure I tested for the right things? </li></ul></ul>
  28. 28. COMPUTER EMERGENCY RESPONSE TEAM (CERT) SECURE CODING BEST PRACTICES <ul><li>Validate input. </li></ul><ul><li>Heed compiler warnings. </li></ul><ul><li>Architect and design for security policies. </li></ul><ul><li>Keep it simple. </li></ul><ul><li>Default deny. </li></ul><ul><li>Adhere to the principle of least privilege. </li></ul><ul><li>Sanitize data sent to other systems (or modules/components) with output filtering. </li></ul><ul><li>Practice defense in depth. </li></ul><ul><li>Use effective quality assurance techniques. </li></ul><ul><li>Adopt a secure coding standard. </li></ul>https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices
  29. 29. INPUT VALIDATION <ul><li>BELIEVE IN NOTHING!! </li></ul><ul><ul><li>Everything that comes from the user/browser is not to be trusted. </li></ul></ul><ul><li>Form values </li></ul><ul><ul><li>Including “hidden” </li></ul></ul><ul><li>HTTP headers </li></ul><ul><ul><li>Including cookies, referrer value </li></ul></ul><ul><li>Environment variables (for CGI scripts) </li></ul><ul><li>How to validate and what to do with bad input? </li></ul>
  30. 30. MORE SECURITY BEST PRACTICES <ul><li>Don’t store passwords in the source code. </li></ul><ul><li>Don’t try to invent your own encryption algorithm. </li></ul><ul><li>Don’t hard-code keys used for encryption or signing. </li></ul><ul><li>Configure and patch your web servers and application servers securely. </li></ul><ul><li>Don’t use insecure APIs. </li></ul>
  31. 31. AGENDA <ul><li>Introduction </li></ul><ul><li>Top Web Application Attacks </li></ul><ul><li>Secure Development Techniques </li></ul><ul><li>Tips for Security with PayPal Products </li></ul>
  32. 32. SECURITY WITH PayPal PRODUCTS <ul><li>Always use HTTPS when talking to PayPal. </li></ul><ul><li>Always integrate with web flows and APIs using POST, not GET. </li></ul><ul><li>Always integrate with PayPal using an HTTP(s) library, not raw sockets. </li></ul><ul><ul><li>Pay attention to HTTP(s) error codes </li></ul></ul><ul><li>Validate IPNs properly. </li></ul><ul><li>Use saved or encrypted Website Payments Standard buttons to prevent tampering attacks. </li></ul><ul><li>Don’t rely on the referrer header during a checkout flow to assume a person has been paid. </li></ul>
  33. 33. CONCLUDING THOUGHTS <ul><li>Be careful about handling input to your application. </li></ul><ul><li>Stay current on security vulnerabilities. </li></ul><ul><li>Harden your servers, frameworks, and applications and keep them up to date. </li></ul><ul><li>By following best practices, your applications will be both more robust and more secure. </li></ul>
  34. 34. MORE INFORMATION <ul><li>Websites </li></ul><ul><ul><li>The Open Web Application Security Project ( http://www.owasp.org ) </li></ul></ul><ul><ul><li>The Web Application Security Consortium ( http://www.webappsec.org/) </li></ul></ul><ul><ul><li>Security Focus ( http://www.securityfocus.com ) </li></ul></ul><ul><li>Online Documents & Books </li></ul><ul><ul><li>Writing Secure Code 2nd Edition by Howard and LeBlanc </li></ul></ul><ul><ul><li>Improving Web Application Security: Threats and Countermeasures ( http://www.microsoft.com/downloads/details.aspx?FamilyId=E9C4BFAA-AF88-4AA5-88D4-0DEA898C31B9&displaylang=en ) </li></ul></ul>
  35. 35. LEARN AND SHARE <ul><li>www.x.com </li></ul><ul><li>Twitter:  @paypalx </li></ul><ul><li>www.facebook.com/paypalx </li></ul><ul><li>Innovate 09 hashtag:  #ppxi09 </li></ul>LEARN AND SHARE www.x.com Twitter: @paypalx www.facebook.com/paypalx Innovate 09 hashtag: # ppxi09 Proprietary

×