Web Security a Programmer’s Perspective
Download 49.46 Kb.
|
- Navigate this page:
- History
- Historical Events
- Security Vulnerabilities
- SQL Injection
- SQL Injection Example
- Prepared Statements
|
Web Security a Programmer’s Perspective Jacob M. Johansen Department of Computer Science University of Wisconsin Platteville johansenj@uwplatt.edu AbstractAs the web becomes ever more a part of our lives in the forms of shopping, banking, communication, and entertainment; the risk to us from malicious users grow. Luckily for programmers there are policies and procedures that we can follow to help mitigate and prevent security breaches for the organizations we work for and help. There are three web programming related security vulnerabilities that will be looked at: cross site scripting, cross site request forgery, and SQL injection. Those three web programming security vulnerabilities make up some of the most costly and damaging security breaches for organizations. Introduction Web Security has come to the forefront of the minds of, people and businesses; as web security related issues have become more frequently headline news. The history of the internet shows that security was lacking from the minds of developers when they were designing the original infrastructure of what we think of today as the internet. From a programmer’s perspective, we can learn what security vulnerabilities look like and how to properly correct these vulnerabilities. The vulnerabilities that will be looked at are Cross Site Scripting, SQL Injections, and Cross Site Request Forgeries. HistoryThe start of what we now call the internet began in 1969 and was called ARPANET. ARPANET stood for the Advance Research Project Agency Network. The Advance Research Project Agency was funded by the Department of Defense: to help route connections, reroute data around nodes that have failed, and to create an open and flexible environment for researchers. Since one of the projects main goals was to be open; security issues at the time of design were not a concern; security was provided by the limited number of computers that were able to connect to the network (namely at universities developing the technology and the department of defense). Historical EventsHistorical web related security events give us some perspective on who is attacking, what the attackers are looking for, and the damage done to the organization that was being attacked. The first company under inspection is Heartland Payment Systems, which was attacked in 2008 by an SQL injection based attack; the attackers were looking for credit card numbers on the Heartland Payment Systems database; the attackers of the Heartland Payment Systems successfully stole 134 million credit card numbers; the attack cost Heartland Payment System’s $139.4 million (Vijayan, 2010). The next incident was Stuxnet, a computer virus; the computer virus was used to slow down Iran’s nuclear enrichment; the best security analysts suspect that the virus was created by nation states (Stuxnet doesn’t specifically relate to web security, but it is important because it shows that countries are entering into the world of creating malicious software.) Finally, the attack on Gawker; Gawker’s data breach involved their user’s credentials, emails and passwords; the main damage to Gawker was their reputation; the attackers were able to uses the stolen credentials to access other sites that Gawker’s users were members of. Security VulnerabilitiesThe security vulnerabilities that will be looked at are SQL Injection (SQLi), Cross Site Scripting (XSS), and Cross Site Request Forgery (XSRF). There will be examples of what each of the vulnerability looks like; the examples of each vulnerability should provide one, help in identifying possible errors during development and code review processes. For each type of vulnerability there will be examples on how to properly protect one’s site from attacks, using today’s best practices. SQL InjectionSQL Injection involves an attacker creating their own partial SQL statement and finding a way to get the developers application to execute their SQL statement. It is important for developers to be aware that SQL injection vulnerabilities are not strictly a web related security issue, but an issue that can affect all software that uses an SQL based database. Since SQL injection based vulnerabilities have historically been some of the most damaging, it is important for developers to be able to: recognize an SQL injectable statement, how to properly create an SQL statement that prevents SQL injection, and how to properly mitigate damages if an SQL injection attack is successful. SQL Injection ExampleTo help understand what a SQL injectable statement looks like, the example in Figure 1 shows what a vulnerable SQL statement could look like in a project. The SQL injection vulnerability is easy to spot in development and code reviews; the main method that programmers use for dynamically built SQL statements (also known as a vulnerable SQL statements) is string concatenation or simple string replacement. The example in Figure 1 will behave as expected under normal use cases, as one can see in Figure 2. Since the program will behave correctly under normal use cases, it is difficult to detect this vulnerability and error through use case testing. Figure 3 shows how the SQL statement from Figure 1 can be manipulated using an attacker’s input; an attacker craft a partial SQL statements to take advantage of the string concatenation method that was used to build the SQL statements. “SELECT * FROM users WHERE uname = ‘” + uname + “’ AND pwd = ‘” + pwd + “’;” Figure : An example of a vulnerable SQL statement in the confines of a program. Uname represents a program variable that contains a user’s username; pwd is a program variable that contains a users’s password. “SELECT * FROM users WHERE uname = ‘Client’ AND pwd = ‘Client Password’;” Figure 2: Shows a statement that is constructed from Figure 1 using a normal use case. “SELECT * FROM users WHERE uname = ‘admin’ AND ‘1’ = ‘1’;--’ AND pwd = ‘’;” Figure 3: Shows a statement that is constructed from Figure 1 using an unusual use case where the uname contained SQL logic of “admin’ AND ‘1’ = ‘1’;--” that changes the logic of the SQL statement. Prepared StatementsPrepared statements are considered the best way to: prevent SQL injections, and to protect ones application. Prepared statements are consider the best practice because it is much easier to detect –in the code– an expression that would allow for a SQL Injection. In a prepared SQL statement, a programmer creates a template which represents the correct logic of the statement, with placeholders (in the examples, the place holder is a ‘?’) which represents user supplied input. When the statement needs to be executed; the template statement is sent to the database and parsed by the database; the application then passes the user supplied input into the database; the server then evaluates the statement knowing which input was supplied by the programmer and what was supplied by the user, this allows the database to execute the statement knowing not to evaluate user supplied input. The first line of code in figure 4 passes the template statement to the database; the second statement in figure 4 passes in the user supplied input to the database and triggers the database to run the query. $stmt = $dbh->prepare(‘SELECT * FROM users WHERE uname = ? AND pwd = ?;’); $stmt->execute($username, $password); Figure 4: Example of a prepared statement in Perl. Stored Procedure Stored procedure are second in the list of preferred strategies for prevent SQL injections. Stored procedures come in a little below prepared statements because there are additional security considerations when using stored procedures: use of parameter binding to prevent “parameter shifting/injection”, and dynamic statement building within the stored procedure offers another possible attack vector; some key words within the stored procedure that would signify a possible injection point are sp_execute, execute, or exec. There are other difference in stored procedures from a programmer’s perspective: stored procedures have their own language, and the logic of the stored procedures is stored in the database. Using a stored procedure, once the procedure has been loaded into the database, is similar to calling other types of SQL statements. The example in figure 5 is what a stored procedure call looks like from within an application; I am skipping over an example of what a stored procedure looks like, as there are many flavors and with major differences. From figure 5, the first line prepares the statement to call the stored procedure, (the SQL statement within the quotes looks very similar to a function call in many programming languages); there are also place holders in the SQL statement, similar to the place holders in prepared statements, but the place holders in stored procedure calls allow for in, out, and in out parameters. The second line from figure 5 binds a variable from the code to the statement; the parameter binding allows for the different types of parameter passing. The third line actually executes the statement on the database. $sth = $dbh->prepare(‘call do_it_1(?);’); $sth->bind_param(1, $count); $sth->execute();
Zip code: \d{5}(-\d{4})? States Example: (AA|AE|AP|AL|AK|AS|AZ|AR|CA|CO|CT|DE|DC|FM|FL|GA|GU| HI|ID|IL|IN|IA|KS|KY|LA|ME|MH|MD|MA|MI|MN|MS|MO|MT|NE| NV|NH|NJ|NM|NY|NC|ND|MP|OH|OK|OR|PW|PA|PR|RI|SC|SD|TN| TX|UT|VT|VI|VA|WA|WV|WI|WY) Figure 6: Example of input validation regular expressions. Cross Site Scripting The term cross site scripting (XSS) is kind of misleading and would probably make more sense if it was referred to as HTML Injection, (I will be using cross site scripting, as it is the term that additional information can be found under.) XSS involves a malicious user finding a way to inject HTML and JavaScript into a web page; the main part of the attack involves JavaScript, as it is JavaScript which allows the attacker to do most of the harm. Two of the dangers of this attack is that it happens silently (the user won’t notice the attack happening) and it allows the attacker to do almost anything a valid user can do. This attack is normally triggered just by visiting the infected page. There are two types of XSS attacks: persistent and non-persistent. Persistent XSS Persistent cross site scripting is when an attacker creates a malicious piece of code (HTML and JavaScript) and injects the malicious code into the database of the website. Once the malicious code is in the database of the website, the malicious code will be inserted into the page when a user requests the infected page. In figure 7 it shows the process of how a persistent XSS attack is placed on the server. The first step in figure 7 is when an attacker sends the malicious code to the web server in some sort of input field; the server processes the data sent and saves the malicious code into the database. The second step is when a valid user requests the infected page from the server. Once the user’s web browser receives the data from the server; the browser then runs the malicious code, which can run commands that look as if they are coming from a valid user. The server will not be able to tell if commands are valid or invalid; the commands will be execute as if they are valid. In 2012 I found a XSS vulnerability of this type in a collaboration application I was working on; so from my experience these attacks are still present in web application today.  Figure 7: Diagrammed process of Persistent Cross Site Scripting attack. Non-Persistent Cross Site Scripting Non-persistent cross site scripting attacks, are attacks that are not located on the server and are more commonly known as reflected cross site cross site scripting attacks. These attacks are normally links that are posted in a common are where a victim normally visits or sent in an email to the victim; the link itself is what contains the malicious HTML and JavaScript that is to be rendered and executed (with some assistance form the web application) by the victim’s web browser. The basis of this type of attack is that the malicious code in the link which the user clicked, is sent to the server; the server then takes the malicious information from the link, renders a page and sends it back to the user; the user browser then executes the injected code. The process that was just described can be better understood by referring to figure 8. Figure 8: Diagrammed process of Non-persistent Cross Site Scripting attack.  Prevention Techniques The only technique (which I have found and currently practice) for preventing cross site script attacks is a set of rules which was described on the open web application security project site: rule zero –never insert untrusted data except in allowed locations; the following rules describe locations that untrusted input allowed and under what safety precautions, rule one –HTML escapei untrusted data before inserting it into an HTML content area (figure 9 provides examples), rule two –attribute escapeii untrusted data before inserting the data into HTML common attributes (figure 10 provides examples), rule three –JavaScript escapeiii untrusted data before inserting the data into JavaScript data values (this rule has unique restrictions and one should research it further), rule 4 –CSS escapeiv and strictly validate untrusted data before inserting the data into an HTML style property values, rule five –URL escapev untrusted data before inserting the data into an HTML URL parameter value, and finally rule 6 –sanitize HTMLvi markup with a Library designed for the job (this last rule was created after the semi-famous MySpace Sammy worm) (The Open Web Application Security Project, 2013). For most project, rules one and two will be sufficient; for any project that needs the other rules (The Open Web Application Security Project, 2013); more research should be done as there are many edge cases that need to be considered. … escaped untrusted data … Directory: ~yangq -> csse411 -> csse411-materials -> f13 csse411-materials -> Emotional Annotation of Text David Gallagher csse411-materials -> Christopher Pinski Department of Computer Science and Software Engineering csse411-materials -> Computer Science / Software Engineering uw-platteville csse411-materials -> Security of Mobile Devices Lon Kastenson Abstract csse411-materials -> Developing for Android Erik Nykl Abstract csse411-materials -> Spyware, Malware, and Viruses Anthony Bosnak Department of Computer Science & Software Engineering University of Wisconsin – Platteville csse411-materials -> Personal Computing: Past, Present, and Future Michael Wills csse411-materials -> Virtual Reality (VR) Kyle Maitland Department of Computer Science University of Wisconsin Platteville f13 -> Discussion of Aspect Oriented Development f13 -> Asynchronous Programming in. Net 5 Cole Durdan Department of Computer Science University of Wisconsin-Platteville Download 49.46 Kb. Share with your friends:
|