Building Secure Web Applications Infographicveracode.com /blog/2012/06/building-secure-web-applications- inf ographic/

Add this Infographic to Your Website for FREE!

Small Version

<p><a href="http://www.veracode.com/products/application-security-elearning.html"><img src="http://www.veracode.com/blog/wp-content/uploads/2012/05/web-security.jpg"></a></p><p>Infographic by <a href="http://www.veracode.com/">Veracode Application Security</a></p>

Large Version

<p><a href="http://www.veracode.com/products/application-security-elearning.html"><img src="http://www.veracode.com/blog/wp-content/uploads/2012/05/web-security.jpg"></a></p><p>Infographic by <a href="http://www.veracode.com/">Veracode Application Security</a></p>

Infographic by Veracode Application Security

the co$t o f 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 customerrecord by up to 62%.

So…what can Web developers be do ing to PREVENT these dat a breaches and Web application vulnerabilit ies fromhappening in the first place?

The OWASP Top 10 Applicat ion 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 Pro tection*

Unvalidated Redirects and Forwards

*May be outside the developer’s contro l

Applicat ion Security Checklist:

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

1. Does the application properly encode or escape data prio r 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. prio r totransmitting 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 pro tect against race conditions that could harm system availabilityand/or data integrity?

5. Does the application ensure that numeric values are within expected ranges that do not result in unanticipatedconsequences when used in calculations or contro l structures?

6. Does the application properly contro l 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 pro tect 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 thatprovides data to the application?

11. Does the application verify the origin o f sensitive requests through the use o f unpredictable, unique nonces as hidden inputform values?

12. Does the application fail gracefully and securely without divulging details o f 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 beentampered with?

14. Does the application perform access contro l checks in a consistent manner across all po tential execution paths?

15. Is the application free o f hardcoded credentials and cryptographic keys?

16. Does the application use sufficient randomness for generating session ids or in o ther security-sensitive contexts?

Specif ic Examples of How to Combat Two Common Flaws

XSS (Cross Site Script ing) 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 o f HTML

URL encode all user input returned as part o f URLs (convert ?, &, /, <, >, and spaces to their respective URL encodedequals)

Convert all user input to a single character encoding before parsing

SQL Inject ion 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 Applicat ions? Security is a Process: Test Everything!

Never assume security contro ls are effective until you can validate them with thorough testing.

Most security vulnerabilities will no t be discovered during normal application use.

Allocate time for dedicated security testing within your pro ject timeline.

Always test applications and application components, both in iso lation and in the environment where the application isdeployed.

Veracode Security Solut ions