OWASP Building Secure Web Applications And the OWASP top 10 vulnerabilities

Background and Material Will Bechtel, Blue Oasis - CISSP 18 years of experience in Software Development, IT and Security. Development of web based applications for Sony, American Express, Cellular One, Federal Express, Sega, US Navy, Wells Fargo. Core of presentation from Open Web Application Security Project (OWASP) –

Overview How Much Security Do You Really Need ? –how to assess the security need and perform risk assessments. Security Guidelines – A set of high level principles that all applications should adhere to. Architecture – Discussion on how Architecture considerations can ensure security where its needed. Authentication – Describes the different types of authentication possible and the common problems. Session Management – Describes the right way to manage sessions and generate session tokens.

Overview (cont) Access Control – Describes access control concepts Event Logging – Describes what to log and how to log user and system events Data Validation – Describes strategies for dealing with unexpected input and what you need to block Common Problems – Describes problems like cross site scripting and SQL Injection and offers practical advise on how to stop them cold Privacy – Discusses privacy issues that may face your application. Cryptography - How to use cryptography and describes some common mistakes.

Risk Management How much security do you need? Risks, threats and vulnerabilities Quantitative approach – utilize SLE x ARO = ALE – Most applicable to physical security or specific asset protection Qualitative approach – ranking of potential risks and their ability to do harm. Subjective. – Because data for the quantitative approach is usually hard to come by, many times a more subjective approach is needed.

Security Guidelines Validate ALL input and output Fail securely Use and reuse trusted components Defense in depth Only secure as the weakest link No security by obscurity Least privilege, separation of privilege

Architecture Design for a secure location – Don’t design in a test lab, then worry about working in a DMZ environment later. – Realize at some point least privilege will be enforced. – There is (usually) a trade-off between convenience and security. Separate, segregate and control access. OS and Network security

Authentication Determining if a user is who they say they are. Browser limitations – consider all input ‘tainted’ HTTP Basic/HTTP Digest Forms based authentication – use SSL Digital certificates Entity Authentication – Cookies

Authentication (cont) Password Based Authentication Schemes – Limits on user names (reduce guessing) – Storing username/passwords – hashing or other secure storage – Ensure password quality – Password lockout, aging and history – Automated password reset strategies – risk remains

Managing User Sessions Cookies Session Tokens Session Management Schemes Access Control and Authorization Event Logging Data Validation

Preventing common problems Cross site scripting (validate) SQL injection (validate) Direct OS commands (URL filter) Directory traversal and path disclosure (URL filter) Null bytes (string termination)

Preventing common problems (cont) Parameter manipulation – URL manipulation – Cookie manipulation – HTTP Header – Form field manipulation

URL manipulation His/her choices are recorded by pressing the submit button. The page is actually storing the entries in form field values and submitting them using a form submit command. The command sends the following HTTP request. A malicious user could construct his own account number and change the parameters as follows: 999

Form field manipulation All of the same rules apply to hidden forms fields as apply to regular form fields. Take the same application. Behind the login form may have been the HTML tag; By manipulating the hidden value to a Y, the application would have logged the user in as an Administrator.

Cookie manipulation The extent of cookie manipulation depends on what the cookie is used for but usually ranges from session tokens to arrays that make authorization decisions. (Many cookies are Base64 encoded; this is an encoding scheme and offers no cryptographic protection). Example from a real world example on a travel web site modified to protect the innocent (or stupid). Cookie: lang=en-us; ADMIN=no; y=1 ; time=10:30GMT ; The attacker can simply modify the cookie to; Cookie: lang=en-us; ADMIN=yes; y=1 ; time=12:30GMT ;

OWASP Top Ten Unvalidated Input Broken Access Control Broken Authentication and Session Management Cross Site Scripting (XSS) flaws Buffer Overflows Injection Problems Improper Error Handling Insecure Storage Denial of Service Insecure Configuration Management

Reasons behind poor web app security Lack of knowledge/education – security has not been a focus for software engineers Lack of quality assurance in general, and specifically lack of security related testing Economic – consumers have been willing to purchase poorly engineered software and have not made this a primary purchasing decision.

Web App security tools Proxy – used to intercept traffic – view/modify data. Web security training apps – – Foundstone’s Hacme Bank -.Net – OWASP Webgoat – Java