Securing Web Application Code by Static Analysis and Runtime Protection

1. Securing Web Application Code byStatic Analysis and Runtime Protection VISHAL KUMAR

2. CONTENTS: • Cross-Site Scripting (XSS) • SQL Injection • General Script Injection • Modeling Web Application Vulnerabilities • Type-Based Analysis • Dataflow Analysis • Static Checking • Runtime Protection • Conclusion

3. 1. INTRODUCTION • WEB APPLICATION VULNERABILITIES • Cross-Site Scripting (XSS) • "A web page contains both text and HTML markup that is generated by the server and interpreted by the client browser. • Web sites that generate only static pages are able to have full control over how the browser interprets these pages. • Web sites that generate dynamic pages do not have complete control over how their outputs are interpreted by the client.

4. The heart of the issue is that if mistrusted content can be introduced into a dynamic page, neither the web site nor the client has enough information to recognize that this has happened and take protective actions." (CERT Coordination Center). • Cross Site Scripting allows an attacker to embed malicious JavaScript, VBScript, ActiveX, HTML, or Flash into a vulnerable dynamic page to fool the user, executing the script on his machine in order to gather data. • The use of XSS might compromise private information, manipulate or steal cookies, create requests that can be mistaken for those of a valid user, or execute malicious code on the end-user systems. The data is usually formatted as a hyperlink containing malicious content and which is distributed over any possible means on the internet.

5. Example of a Cross Site Scripting attackAs a simple example, imagine a search engine site which is open to an XSS attack. The query screen of the search engine is a simple single field form with a submit button. Whereas the results page, displays both the matched results and the text you are looking for. • Example:Search Results for "XSS Vulnerability" • To be able to bookmark pages, search engines generally leave the entered variables in the URL address. In this case the URL would look like: • http://test.searchengine.com/search.php?q=XSS%20 Vulnerability • Next we try to send the following query to the search engine:

6. <script type="text/javascript"> alert('This is an XSS Vulnerability') </script> • By submitting the query to search.php, it is encoded and the resulting URL would be something like: • http://test.searchengine.com/search.php?q=%3Cscript%3 • Ealert%28%91This%20is%20an%20XSS%20Vulnerability%92%2 • 9%3C%2Fscript%3E • Upon loading the results page, the test search engine would probably display no results for the search but it will display a JavaScript alert which was injected into the page by using the XSS vulnerability.

7. WEB APPLICATION VULNERABILITIES • SQL Injection SQL injection is an attack in which malicious code is inserted into strings that are later passed to an instance of SQL Server for parsing and execution.  Example: The following script shows a simple SQL injection. The script builds an SQL query by concatenating hard-coded strings together with a string entered by the user: varShipcity; ShipCity = Request.form ("ShipCity"); varsql = "select * from OrdersTable where ShipCity = '" + ShipCity + "'";

8. SQL Injection: • The user is prompted to enter the name of a city. If she enters Redmond, the query assembled by the script looks similar to the following: SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond' • However, assume that the user enters the following: Redmond'; drop table OrdersTable-- • In this case, the following query is assembled by the script: SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';drop table OrdersTable--'

9. SQL Injection: • The semicolon (;) denotes the end of one query and the start of another. The double hyphen (--) indicates that the rest of the current line is a comment and should be ignored. If the modified code is syntactically correct, it will be executed by the server. When SQL Server processes this statement, SQL Server will first select all records in OrdersTable where ShipCity is Redmond. Then, SQL Server will drop OrdersTable.

10. General Script Injection: Script injection attacks occur when a hacker takes a few lines of malicious programming code and enters it in to a form on our Website and then submits the form. For Example: exec("htpasswd.exe -b .htpasswd". "{$_POST['user']} {$_POST['pass']}"); • The intent for this code is to allow survey administrators to change user passwords for system access. Consider a malicious survey administrator who sends an HTTP request with: user ="; NET USER foo /ADD" and pass="", then the actual command becomes: htpasswd.exe -b .htpasswd; NET USER FOO /ADD This results in creation of new user “foo” with logon rights.

11. General Script Injection: • Allowing users to upload files is a pretty typical feature on the web these days • The HTTP request variable “csvfile” is used as an argument to call fopen(), which allows arbitrary files to be opened. • A subsequent code section delivers the opened file to the HTTP client, allowing attackers to download arbitrary files. $csvfile = $_POST['csvfile']; if($_POST['action'] == 'download') $fp=fopen($csvfile,'rb');

12. Modeling Web Application Vulnerabilities: The primary objectives of information security systems are to protect confidentiality, integrity, and availability For Web applications, compromises in integrity are the main causes of compromises in confidentiality and availability. The relationship is illustrated in the following Figure

13. Modeling Web Application Vulnerabilities:

14. Type-Based Analysis: • The first widely accepted model for secure information flow has two axioms: a) a subject cannot access information classified above its clearance b) a subject cannot write to objects classified below its clearance. • This model can be enforced using a type system in which program variables are associated with security classes that allow inter-variable information flow to be statically checked for correctness. • Type-based approaches prove program correctness without unreasonable computation efforts. Their main drawback is their high false positive rate, which often makes them impractical for real-world use

15. Dataflow Analysis: • For gathering information about the possible set of values calculated at various points in a computer program. • A program's control flow graph (CFG) is used. •  A simple way to perform dataflow analysis of programs is to set up dataflow equations for each node of the control flow graph and solve them by repeatedly calculating the output from the input locally at each node until the whole system stabilizes, i.e., it reaches a fix point.

16. Static Checking: • The goal of static checking is simply to find software bugs. • Static code analysis is the analysis of computer software that is performed without actually executing programs built from that software • In most cases the analysis is performed on some version of the source code and in the other cases some form of the object code.

17. Runtime Protection: • In many situations, it is difficult for static analysis to offer satisfactory runtime program state approximation. • In dynamically typed languages such as Lisp and Scheme, a common approach is to perform runtime type checking for objects whose types were undeterminable at compile-time. These kinds of dynamic checks are extremely expensive, resulting in the creation of such static optimization techniques as dynamic typing and soft typing to reduce the number of runtime checks.

18. Conclusion • Security remains a major roadblock to universal acceptance of the Web for many kinds of transactions, especially since the recent sharp increase in remotely exploitable vulnerabilities have been attributed to Web application bugs. • There are some applications which offer protection methods that immediately ensure the security of Web applications, but they require careful configuration by experienced administrators.

19. REFERENCES: • Yao-Wen Huang+*, Fang Yu*, Christian Hang#, Chung-Hung Tsai+, D. T. Lee+*, Sy-Yen Kuo+ “Securing Web Application Code byStatic Analysis and Runtime Protection”, Proceedings of the 13th international conference on World Wide Web. • Allen, F. E, Cocke, J. “A Program Data Flow Analysis Procedure.” Communications of the ACM, 19(3):137-147, March 1976. • Andrews, G. R., Reitman, R. P. “An Axiomatic Approach to Information Flow in Programs.” ACM Transactions on Programming Languages and Systems, 2(1), 56-76, 1980. • Denning, D. E. “A Lattice Model of Secure Information Flow.” Communications of the ACM, 19(5):236-243, 1976. • Foster, J., Terauchi, T., Aiken, A. “Flow-Sensitive Type Qualifiers.” In Proc. ACM SIGPLAN 2002 Conf. Programming Language Design and Implementation (PLDI2002), pages 1-12, Berlin, Jun 2002. • Hecht, M. S., Ullman, J. D. “Analysis of a Simple Algorithm For Global Flow Problems.” In Conference Record of the First ACM Symp. Principles of Programming Languages (POPL’73), pages 207-217, Boston, Massachussets, 1973. • Jensen, T., Le Metayer, D., Thorn, T. “Verification of Control Flow Based Security Properties.” In Proc. 20th IEEE Symp. Security and Privacy, pages 89-103, IEEE Computer Society, New York, USA, 1999. • Schneider, F. B. “Enforceable Security Policies.” ACM Transactions on Information and System Security, 3(1):30-50, Feb 2000. • Volpano, D., Smith, G., Irvine, C. “A Sound Type System For Secure Flow Analysis.” Journal of Computer Security, 4(3):167-187,1996. • Watts, G. “PHPXref: PHP Cross Referencing Documentation Generator.” Sep 2003. http://phpxref.sourceforge.net/

20. Thank You…