Web Security a Programmer’s Perspective



Download 49.46 Kb.
Date conversion29.01.2017
Size49.46 Kb.


Web Security a Programmer’s Perspective

Jacob M. Johansen

Department of Computer Science

University of Wisconsin Platteville

johansenj@uwplatt.edu


Abstract

As 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.

History

The 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 Events

Historical 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 Vulnerabilities

The 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 Injection

SQL 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 Example

To 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 Statements

Prepared 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();

Figure 5: Example of a stored procedure call in Perl.


Escaping
Escaping all user supplied input is an option of last resort. The protection that escaping provides is better than nothing, but is fallible as the method relies on searching for possible injection cases and replacing them with characters that prevent the injection case; there are possible injection cases that have not yet been discovered, so the undiscovered cases cannot be protected against. Knowing the limitations of the escaping method, it is advisable to use a well maintained library to do the escaping of untrusted user input; a well maintained library provides the programmer the confidence that the escaping method will catch the known vulnerabilities. The escaping method is most commonly used to retrofit an old application. The reason the escaping method is used for retrofitting is that it provides a more cost effective method for adding security to an older application.
Additional Defenses
Additional defenses are also an important part of SQL injection prevention and mitigation (these defenses will help prevent SQL injections and lessen the damage to the organization if a SQL injection attack is successful.) The main additional security methods are least privilege, input validation, and database field protection. The least privilege method involves setting up the database to limit access to the tables, to only allow the running needed commands: write, read, and delete a row (this is not so much from a programmer’s prospective, but it is still important as a lot of developers are also assigned with the responsibility to setup the database.) Input validation helps verify that the data the user sends is what the application is expecting; figure 6 contains two example of some regular expressions that have been used to verify some common types of input. Field protection contains two different types: hashing and encryption. Hashing’s main use is to protect what a user choses for a password; using proper password hashing technics allows the storage of the users password without storing the password in clear text; the hashing method makes it almost impossible for an attacker to figure out the users password in the event of a successful attack. The other type of field protection is encryption and should be used to store things such as credit card numbers; the encryption needs to be done in the application, using the database supplied encryption method will not protect sensitive information from an attack, as the database will unencrypt the sensitive information during an SQL injection attack.

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.

c:\users\johansenj\desktop\persistant.png




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.

c:\users\johansenj\desktop\nonpersistant.png



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 …


The database is protected by copyright ©ininet.org 2016
send message

    Main page