Developing Secure Applications and Defending Against Common Attacks

DEVELOPING SECURE APPLICATIONS AND DEFENDING AGAINST ATTACKS Andy Steingruebl, Manager, Information Risk Management

AGENDA
Introduction
Top Web Application Attacks
Secure Development Techniques
Tips for Security with PayPal Products

WHEN SECURITY FAILS

TYPICAL SECURITY MEASURES IN A BANK

AGENDA
Introduction

THE PROBLEM OF SECURITY
Large and complex systems interact to make perfect security impossible.
New vulnerabilities are discovered almost every day.
Authorized users misuse access.

A BRIEF HISTORY OF SECURITY ISSUES 1994 Amazon 1995 Yahoo! 1998 Google 2005 YouTube

OPEN WEB APPLICATION SECURITY PROJECT (OWASP) TOP 10
Cross Site Scripting (XSS)
Injection flaws
Malicious file execution
Insecure direct object reference
Cross Site Request Forgery (CSRF)
Information leakage and improper error handling
Broken authentication and session management
Insecure cryptographic storage
Insecure communications
Failure to restrict URL access
Source: http://www.owasp.org/index.php/Top_10_2007

WEB APPLICATION SECURITY CONSORTIUM (WASC) THREAT CLASSIFICATION
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.
Found at http://www.webappsec.org/projects/threat/

CROSS SITE SCRIPTING (XSS)
What if <iframe src="http://en.wikipedia.com" height="1180" width="100%"></iframe> was somebody’s name?

CROSS SITE SCRIPTING (XSS)
XSS Code allows an attacker to:
Exploit the user’s trust for a web site
Make requests using victim’s credentials
Alter the website (phishing attacks)
Track user activity
Hijack a user’s session
Provide an attack vector used by web focused worms

XSS MITIGATION
Output filtering
Encode fields to escape HTML in output (HTML entity encoding)
Use context-appropriate encoding
Input validation
Don’t trust user input
Validate using a white list
Cookie security flags
HTTP only
Secure (not an XSS protection, but still a good idea)

CROSS SITE REQUEST FORGERY (CSRF)
Takes advantage of a website’s trust of a user
Example: A user is sent an email with an image link. When they load the email, it tries to load an image.
<image src=“https://www.yourbank.com/ tranfer_money?to=attacker_account& amount=1000”>

CSRF MITIGATION
Use CSRF tokens.
Tokens must be associated with the user’s session.
The combination of cookie and token must be unique and received within a specific window of time.
OR
Require users to re-authenticate before performing sensitive transactions.

SQL INJECTION
Flaw when SQL statements are formed by string concatenation
statement = "SELECT * FROM users WHERE name = '" + userName + "'";
What if the user enters: "' or 'x'='x" ?
Source: http://xkcd.com/327/

MITIGATING SQL INJECTION
Validate all input parameters accepted by the web application.
Create SQL queries in a secure manner.
Like PreparedStatement or CallableStatement
Parameterized queries are not vulnerable to most types of SQL injection attacks.

ATTACKING LOGIN FUNCTIONALITY
Typical attacks against login functionality
Username enumeration
Password guessing
Brute-force attacks
Authentication mechanism attack
For example, ‘Basic Web Server Authentication’ is really a Base64 encoded username/password passed in headers without encryption Authorization: Basic RG9udFVzZVRoaXNQYXNzd29yZA==

MITIGATING LOGIN ATTACKS
Develop generic error messages.
Enforce account lockout after failed log in attempts.
Implement account lockout until reset.
Make sure account lockout triggers notification.
Implement server-side enforcement of password syntax and strength.

COMMON SHOPPING CART ATTACKS
Price tampering
Fake referrer header attack

PRICE TAMPERING
One of the oldest web attacks
Defense is fairly straightforward
Store price information in server-side state
Employ effective controls during shipping processes
Recommended PayPal Products include Website Payments Standard saved buttons and Express Checkout

REFERER HEADER ATTACKS
Do not rely on HTTP REFERER header for security decisions.
REFERER can be tampered with by the end user.
For instant-fulfillment requirements, we strongly recommend PayPal Express Checkout.
If you use Website Payments Standard, make sure to confirm payments before delivering goods to the customer.

APPLICATION SECURITY TESTING
The simplest application security testing tools are client-side proxies
Burp
Paros
Fiddler
WebScarab
Browser plug-ins can also help
Tamper Data
HttpWatch
Free, commercial tools exist to automate security testing
AppScan
WebInspect

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.

AGENDA
Introduction

APPLICATION SECURITY AND SDLC
“ 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.”
Gartner
“ The only people who can solve software security are the builders.”
Gary McGraw, “Building Secure Software”
“ The cost of removing an application security vulnerability during the design/development phase ranges from 30-60 times less than if removed during production.”
NIST, IBM, and Gartner
Several standards and regulatory compliance requirements directly or indirectly mandate the need for application security controls - PCI DSS, ISO 17799/27001, SOX, GLBA, etc.

SECURITY IN SDLC
Ensure that both design and implementation security-related bugs don’t get released into production.
Security in SDLC

WHY BEST PRACTICES?
Why best practices?
Can make code easier to read and less ambiguous
Solves some problems
More robust in the face of change
Reduces the likelihood of common flaws
Dangerous areas are clearly marked
Secure development can benefit from checklists
Did I make sure to check for error conditions?
Did I make sure I avoided banned behaviors?
Did I make sure I tested for the right things?

COMPUTER EMERGENCY RESPONSE TEAM (CERT) SECURE CODING BEST PRACTICES
Validate input.
Heed compiler warnings.
Architect and design for security policies.
Keep it simple.
Default deny.
Adhere to the principle of least privilege.
Sanitize data sent to other systems (or modules/components) with output filtering.
Practice defense in depth.
Use effective quality assurance techniques.
Adopt a secure coding standard.
https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices

INPUT VALIDATION
BELIEVE IN NOTHING!!
Everything that comes from the user/browser is not to be trusted.
Form values
Including “hidden”
HTTP headers
Including cookies, referrer value
Environment variables (for CGI scripts)
How to validate and what to do with bad input?

MORE SECURITY BEST PRACTICES
Don’t store passwords in the source code.
Don’t try to invent your own encryption algorithm.
Don’t hard-code keys used for encryption or signing.
Configure and patch your web servers and application servers securely.
Don’t use insecure APIs.

AGENDA
Introduction

SECURITY WITH PayPal PRODUCTS
Always use HTTPS when talking to PayPal.
Always integrate with web flows and APIs using POST, not GET.
Always integrate with PayPal using an HTTP(s) library, not raw sockets.
Pay attention to HTTP(s) error codes
Validate IPNs properly.
Use saved or encrypted Website Payments Standard buttons to prevent tampering attacks.
Don’t rely on the referrer header during a checkout flow to assume a person has been paid.

CONCLUDING THOUGHTS
Be careful about handling input to your application.
Stay current on security vulnerabilities.
Harden your servers, frameworks, and applications and keep them up to date.
By following best practices, your applications will be both more robust and more secure.

MORE INFORMATION
Websites
The Open Web Application Security Project ( http://www.owasp.org )
The Web Application Security Consortium ( http://www.webappsec.org/)
Security Focus ( http://www.securityfocus.com )
Online Documents & Books
Writing Secure Code 2nd Edition by Howard and LeBlanc
Improving Web Application Security: Threats and Countermeasures ( http://www.microsoft.com/downloads/details.aspx?FamilyId=E9C4BFAA-AF88-4AA5-88D4-0DEA898C31B9&displaylang=en )

LEARN AND SHARE
www.x.com
Twitter: @paypalx
www.facebook.com/paypalx
Innovate 09 hashtag: #ppxi09
LEARN AND SHARE www.x.com Twitter: @paypalx www.facebook.com/paypalx Innovate 09 hashtag: # ppxi09 Proprietary

Developing Secure Applications and Defending Against Common Attacks

by PayPalX Developer Network on Nov 10, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

3 Embeds 9

Statistics

Developing Secure Applications and Defending Against Common Attacks — Presentation Transcript

http://www.slideshare.net	5
http://www.schoox.com	3
http://blog.collectivecube.com	1