OWASP Security

OWASP is abbreviation for Open Web Application Security Project.

The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are.

• TOC

  {:toc}

1. SQL Injection

Reason

• Targets the back-end data stores via URL, forms, login boxes

Defense

• The best defense against SQL injection is use parameterized queries (prepared statements) for SQL queries within the code

• No detailed database error message returned directly

• Validate the input data before constructing SQL

2. Session hijacking

Reason

• Network packet captured, SessionID being used, hijacker treated as user

Defense

• Encryption of the site over HTTPS will help prevent session tokens from being stolen

• Sensitive sites consider not only authentication but also the entire sites: Use SSL, HTTPS

• Shorter idle timeouts

• Help those who forgot to logout

• Harder for hijackers to act

3. Cross-site Scripting (XSS)

Reason

• User supplied input is properly escaped, or not verify it to be safe via input validation

Defense

• Use proper re-encoding before redisplaying user input

• Properly escape all untrusted data based on the HTML context

• Positive or “whitelist” input validation

• Auto-sanitization libraries

• Content Security Policy (CSP)

4. Parameter Manipulation (insecure direct object reference)

Reason

• Parameter values contained inside a URL being modified get different functionality or data

Defense

• Server-side validation

• Central validation scheme

• Independent business logic

• Session variables

• Storing data in session variables, no parameters in the URL to be tampered with

5. Insecure Configuration

Reason

• Lack of standard hardening process for deployed infrastructure and software

• No central account management mechanism in place on each server

• No standardized and central process for patch management

Defense

• Repeatable Hardening process

• New server, repeatable hardening scripts

• Patch Management

• Regular Updates and Audits

6. Insecure Storage

Reason

• Sensitive data may be disclosed to unauthorized party

Defense

• Determine what’s sensitive

• Thread Modeling

• Use known strong algorithms

• Hashing

• Use >=168bits, e.g. SHA-256, instead of MD5, SH0, SH1

7. Forcible Browsing

Reason

• Access by “guessing” the URL

Defense

• Page Level Authorization

• Each page checks to see if the user is authorized to have access

• Programmed Authorization

• Code and programming to determine a user’s authorization, includes coding roles and access policies

8. Cross-site request forgery (XSRF)

Reason

• Victim must be authenticated

• Hacker must be able to make a XSRF URL, attack is blind

Defense

• Decrease session timeouts

• XSRF tokens, adding a secret, not automatically submitted, token to ALL sensitive requests

• Server generates a token on each page load and stores it, when submits the form, it check if the token matches

• Re-authentication

• Asking user to re-authenticate before a sensitive transaction is a good way to verify the user and their intended actions

9. Vulnerable Components

Reason

• Vulnerable components are common, virtually every app has these issues; development team not enforcing components/libraries up-to-date

Defense

• Automation checks periodically to check if libraries out-of-date

10. Unchecked Redirects

• URL redirects exploited by hacker

Defense

• Don’t use parameters (in URL), manage re-direction in code such as session data

• Server side validation, check redirect URLs, use a whitelist

Reference

• OWASP Top 10
• OWASP_Top_Ten_Cheat_Sheet
• OWASP Node Goat Tutorial: Fixing OWASP Top 10
• Node.js Security Checklist