SEC511 Principles of Information Assurance and Security Lecture 7 Web Security

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

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. The end Reading: Stuttard, Chapters 1 and 9.