WEB ATTACKS

1. WEB ATTACKS BCIS 4630 Fundamentals of IT Security Dr. Andy Wu

2. Overview • Web encoding • XSS • SQL injection

3. Web Apps: What Can Go Wrong • Web platform • Platform software (OS, IIS, etc.) may contain vulnerabilities. • Client software • Browser functionalities, e.g., scripting support, plug-ins, can be abused. • Web application • Authentication mechanism or program logic may have flaws. • Session management mechanisms, e.g., cookies, sessions, can be manipulated. • Database server • Malicious database queries compromise confidentiality or execute commands. • Transport • Traffic between the client and the server can be sniffed.

4. Web Platforms • Attacks can be launched by: • Finding the vulnerabilities in the platform on which the Web server is running, e.g., server OS, Web server application. • Tempering with the information in the browser’s URL bar, HTTP header, input in fields in an HTML form, etc. • Non-ASCII Encoding schemes can be used to obfuscate the attack and evade detection.

5. Encoding • Web pages and URLs largely use the ASCII character set. However, some characters have special meanings and could cause confusion if entered as ASCII characters. • Also, HTTP does not allow spaces in the URL. • Alternative encoding schemes, therefore, were created to encode characters. • Unfortunately, they are largely HEX-based and the resultant patterns of characters look cryptic compared with their ASCII counterparts. • To untrained eyes, the meaning of a string of non-ASCII characters is not readily interpretable.

6. URL Coding • Characters are represented in a URL as a percent sign directly followed by the two-digit HEX equivalent to the character’s ASCII value. • The encoded form is called a “URL escape”. • They are often seen in phishing emails as a way to obfuscate the nature of the URL.

7. Base64 • Base64 is used to code and decode binary data (0s and 1s) as printable ASCII characters. • It processes 3 bytes (24 bits) at a time. To ensure that the coding results in printable ASCII characters, it takes 6 bits out of the 24, finds its decimal equivalent, converts it to a printable character, and then the next 6. • Using six bits meaning that there are 2^6 = 64 possibilities:10 digits, 26 lower caseletters, 26 uppercase letters, the plus sign (+), and the forward slash (/). • Email handles binary in Base64.

8. UTF-7 • The English characters can be sufficiently handled with the default UTF-8 scheme. • To represent characters not found in English, alternatives have to be used, e.g., Unicode, UTF-7, etc. • UTF-7 is a widely supported scheme. It converts Unicode into ASCII values.

9. IIS Vulnerabilities • In 1997, the L0pht crew showed that Microsoft Internet Information Server (IIS) treated different representation of the character . (dot) differently. • Requesting the file login.asp displayed the regular HTML page. • Requesting the file login%2easp displayed the source code of the file. • In 2001, Microsoft reported that entering http://<server>/..%c0%af..%c0%af..%c0%af..%c0%af..%c0%afwindows..%c0%afsystem32..%c0%afcmd.exe(equivalent to http://<server>/../../../../../../windows/system32/cmd.exe, which normally would be blocked) would bypass blocking and give the attacker a command console to run commands on the Web server.

10. Cross-Site Scripting • An attacker can connect to the server and hide malicious scripts on the server. • He/she then sends the victim a link to the infected page on the server. In the link, he/she includes text such as the <script>tag that will invoke the malicious script on the server. • If the victim clicks the link, the page is requested from the server. However, the <script> tag in the link is included as part of the HTML streamed from the server to the client. • The victim’s browser processes the HTML and when it comes across the <script> tag it invokes the script. • The malicious code can steal the victim’s information such as session ID cookie and passes it to the attacker. • With the victim’s session ID cookie, the attacker can impersonate the victim.

11. XSS Attack on My 3680 Example

12. XSS Attack • The success of the XSS attack relies on injecting unexpected HTML code by manipulating the URL, hence another name “HTML injection”. • To fool the victim and to evade detection, obfuscating the angle brackets and any other unusual characters is essential. This can be done by using URL encoding, UTF-7, etc. For example: http://localhost:8080/eastwind/validate2.jsp?username=%3Cscript%3Ecross%28%29%3C/script%3E

13. Session Hijacking • An attacker can get access to the session ID of a logged-in user. Ways to get a session ID: • Guessing • Brute forcing • Trial and error • Referer in HTTP header • Packet sniffing • Cross-site scripting • The attacker can then install the session ID in his own browser and present it to the server. • The server would believe that it is communicating with the authenticated user and give the attacker access to data that the victim would have access to.

14. SQL Injection • A web application normally builds queries based on inputs taken from web/HTML controls, such as textboxes, and then passes the query to the database server. • An attacker may be able to modify or add queries that are sent to a database server by playing with input to the web application. • If the application code is unable to detect characters in the user input that have special meaning in SQL, the attacker may be able to do more than what the web application was designed to do.

15. What Can SQL Injection do? • Bypass logins • Modify data • Delete rows or entire tables • Execute console commands • Read hidden data • Steal credentials

16. SQL Injection • Code for handling input username = txtUsername.Text.ToString(); password = txtPassword.Text.ToString(); cmdGetUserInfo.CommandText = "SELECT * FROM User WHERE UserName='" + username + "' AND Password='" + password + "'";

17. SQL Injection • The SQL statement that is assembled after the user submits the form SELECT * FROM User WHERE Username='andy' OR 'a'='a' AND Password='' • Since the AND part is evaluated before the OR part, and “a” is always equal to “a”, the statement is in effect evaluated as: SELECT * FROM User WHERE UserName='andy' OR TRUE • As long as the username “andy” exists, this query will retrieve the row. • Thus, the password becomes useless.

18. Prevention with Good Coding Practice • Use strongly typed variables and database column definitions. • Assign query results to a strongly typed variable. • Limit data lengths. • Apply data separation and role-based access within the database. • Avoid creating queries via string concatenation. • A good, though not perfect, prevention is to use stored procedures. • With stored procedures, attacker input is more likely to be evaluated as illegal or to return no matches.

19. Stored Procedures • In the previous example, the malicious input (andy OR ‘a’=‘b) will be treated by the database server as the value of the @username parameter rather than part of the SQL statement. • It is not possible for an attacker to manipulate the entire query. Create Procedure GetUserInfo As Declare @Username varchar Declare @Password varchar Set @Username = "" Set @Password = "" SELECT * FROM User WHERE Username = @Username AND Password = @Password GO

20. Other Preventive Measures • Permissions • Multiple database accounts • Awareness • Pay attention to where your data comes from • Think like a hacker when programming • Patch ASAP • Conceal Errors