Building Secure Web Applications Infographic

Neglecting to take proper security measures at the application layer is one of the most common causes of data breaches, yet many companies still leave their applications unprotected. Securing your applications begins with developer training on the risks applications face and the methods required for vulnerability prevention. This infographic focuses on defining these risks and combating common flaws.

• the co$t of a data breach averages $5.5 million or $194 per customer record
• Companies that take security seriously by employing a Chief Information Security Officer can reduce the cost per customer record by up to 62%.
• So…what can Web developers be doing to PREVENT these data breaches and Web application vulnerabilities from happening in the first place?

The OWASP Top 10 Application Security Risks

• Injection
• Cross-Site Scripting (XSS)
• Broken Authentication and Session Management
• Insecure Direct Object References
• Cross-Site Request Forgery (CSRF)
• Security Misconfiguration*
• Insecure Cryptographic Storage
• Failure to Restrict URL Access
• Insufficient Transport Layer Protection*
• Unvalidated Redirects and Forwards

*May be outside the developer’s control

Application Security Checklist:

(This is not a comprehensive list, as application security is a constant process)

1. Does the application properly encode or escape data prior to exchanging it with external components such as a database, LDAP server, web browser, etc?
2. Does the application encrypt sensitive information such as authentication credentials, sensitive customer data, etc. prior to transmitting such information across the network?
3. Does the application comply with the organization’s existing security standards?
4. Does the application use thread-safe techniques to protect against race conditions that could harm system availability and/or data integrity?
5. Does the application ensure that numeric values are within expected ranges that do not result in unanticipated consequences when used in calculations or control structures?
6. Does the application properly control access to the server’s file system?
7. Does the application use currently accepted, industry-standard cryptographic algorithms?
8. Has the application been deployed with secure default permissions?
9. Does the application protect against brute force attacks?
10. Does the application validate all input including parameters, arguments, cookies, anything read from the network, environment variables, request headers, URL components, e-mail, files, database records and any external system that provides data to the application?
11. Does the application verify the origin of sensitive requests through the use of unpredictable, unique nonces as hidden input form values?
12. Does the application fail gracefully and securely without divulging details of the underlying implementation to the end user?
13. Does the application store state information on the server side only or ensure client-side state variables have not been tampered with?
14. Does the application perform access control checks in a consistent manner across all potential execution paths?
15. Is the application free of hardcoded credentials and cryptographic keys?
16. Does the application use sufficient randomness for generating session ids or in other security-sensitive contexts?

Specific Examples of How to Combat Two Common Flaws

XSS (Cross Site Scripting) Flaws

You May Be Vulnerable If…

• Input coming into your applications is not validated
• Output to the browser is not properly escaped

How to Prevent It

• Use the appropriate escaping method for the context you are in. Here are some examples:
• HTML encode all user input returned as part of HTML
• URL encode all user input returned as part of URLs (convert ?, &, /, <, >, and spaces to their respective URL encoded equals)
• Convert all user input to a single character encoding before parsing

SQL Injection Flaws

You May Be Vulnerable If…

• Unvalidated user input is concatenated into an ad-hoc SQL query

How to Prevent It

• Use parameterized prepared statements
• Use Input Validation for Length, Type, Syntax & Business rules
• Use the lowest privilege database account possible

Really Want Secure Web Applications? Security is a Process: Test Everything!

• Never assume security controls are effective until you can validate them with thorough testing.
• Most security vulnerabilities will not be discovered during normal application use.
• Allocate time for dedicated security testing within your project timeline.
• Always test applications and application components, both in isolation and in the environment where the application is deployed.