Software Security - Vulnerability&Attack

Software Security Vulnerability Analysis
Emanuela Boroș

Emanuela Boroș

“Al. I. Cuza” University, Faculty of Computer Science

Master of Software Engineering, II

Page 1 /15

Emanuela Boroș

Table of Contents
1. Overview..........................................................................................................................................3

2. Web application vulnerabilities........................................................................................................3

a) Input Validation...........................................................................................................................7

3. SQL Injection...................................................................................................................................7

a) State-of-the-art.............................................................................................................................7

b) SQL Injection Example...............................................................................................................9

c) Protecting against SQL Injection...............................................................................................10

d) Java specific Protecting against SQL Injection..........................................................................11

6. SQL Injection Scanners..................................................................................................................13

a) Pangolin.....................................................................................................................................13

1. Database Support..............................................................................................................13

2. Sample use of Pangolin....................................................................................................13

b) GreenSQL.................................................................................................................................15

c) Add-ons for Firefox...................................................................................................................15

1. SQL Inject Me..................................................................................................................15

7. Bibliography...................................................................................................................................15

Page 2 /15

Emanuela Boroș

1. Overview

Every day, increasingly, organizations face security risks imposed upon them by
attackers intent on achieving fame, glory, or profit. Attackers, familiar with common
vulnerabilities inherent in many of today's websites, know how to exploit those
vulnerabilities with attacks designed specifically to take advantage of them. 1 A
vulnerability is a weakness in the application, which can be a design flaw or an
implementation bug, that allows an attacker to cause harm to the stakeholders of an
application. Stakeholders include the application owner, application users, and other
entities that rely on the application. 2 In order to create an application that has a
decreasing number of vulnerabilities it is needed a solid foundation for designing,
building, and configuring secure web applications.
Number 1 in the Top 10 most critical web application security vulnerabilities 3
identified by the Open Web Application Security Project (OWASP)4 is Injection Flaws.
Injection happens whenever an attacker's data is able to modify a query or command sent
to a database, LDAP server, operating system. Types of injections are SQL, LDAP,
XPath, XSLT, HTML, XML, OS command. SQL injection and Cross-Site Scripting
account for more than 80% of the vulnerabilities being discovered against web
applications5 (SANS Top Cyber Security Risks6).
It's hard to believe, but SQL injection has been around for 13 years. SQL injection is as
prevalent as ever as highlighted in The 2011 Mid-Year Top Cyber Security Risks
Report7. In 1998 – 1999, Internet security was all about firewalls and SSL. Most people
tend to think of security as a network problem. The truth: security is often a software
problem.

2. Web application vulnerabilities

Hackers today have an ever increasing list of weaknesses in the web application structure
at their disposal, which they can exploit to accomplish a wide variety of malicious tasks.
New flaws in web application security measures are constantly being researched, both by
hackers and by security professionals. Most of these flaws affect all dynamic web
applications whilst others are dependent on specific application technologies. In both
cases, one may observe how the evolution and refinement of web technologies also
brings about new exploits which compromise sensitive databases, provide access to
theoretically secure networks, and pose a threat to the daily operation of online
businesses.
Based on data pulled from The Open Source Vulnerability Database (OSVDB) 8, the
total number of new vulnerabilities reported for the first half of 2011 is about 25% lower
than the number of new vulnerabilities reported at mid-year 2010 and previous years. As
of June 30, 2011, OSVDB cataloged 3,087 reported vulnerabilities in Internet-based

1 The 2011 Mid-Year Top Cyber Security Risks Report http://h20195.www2.hp.com/v2/GetPDF.aspx/4AA3-
7045ENW.pdf
2 https://www.owasp.org/index.php/Category:Vulnerability
3 https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
4 https://www.owasp.org/index.php/Main_Page
5 http://weblogs.java.net/blog/caroljmcdonald/archive/2009/10/02/top-10-web-security-vulnerabilities-num-
ber-2-injection-flaws
6 http://www.sans.org/top-cyber-security-risks/
7 http://www.acunetix.com/blog/web-security-zone/articles/sql-injection-prevalent-hack/
8 The Open Source Vulnerability Database, http://osvdb.org/
Page 3 /15

Emanuela Boroș

systems, applications, and other computing tools, as compared to 4,091 cataloged in the
corresponding period in 2010.

After peaking in 2006, vulnerability reporting has been in a slow decline. The reasons for
this decline are varied, but several likely reasons stand out. Software makers and system
developers have increased their security awareness and have taken steps to reduce
vulnerabilities prior to releasing their products. The second reason is a reduction in the
disclosures of discovered vulnerabilities, motivated by a desire to instead sell the
vulnerability for profit. Another is that some organizations would rather announce details
regarding vulnerabilities only after they've been fixed.
Despite the overall decline in new vulnerabilities being discovered and reported, it is
important to note that the ratio of vulnerabilities discovered in web applications still
makes up 31% of all vulnerabilities disclosed. It is worth noting that roughly half of all
vulnerability disclosures since 2006 have involved Web applications, so the downward
trend for the first half of 2011 is yet another proof point for the overall drop in
vulnerability disclosure thus far.
The reason for the high number of web application vulnerabilities is a matter of
opportunity and profit. First, the number of web applications in circulation grows steadily
every day. A web application in its simplest form ties together an operating system, a
web server, a database, and some top-level application that customers use to interact with
the back-end systems. Many organizations have adopted this model for interacting with
customers through retail sites, online banking or finance applications, or even
appointment scheduling. In addition, many organizations have confidential or sensitive
data stored in the databases connected to these applications, offering an almost limitless
field of opportunity for attackers, who view it all as a very lucrative proposition.
First of all, there has to be defined a set of application vulnerability categories in order to
know what type of attacks can appear. There are common categories that span multiple
technologies and components in a layered architecture. These categories are the focus for
designing are building secure web applications. 9

9 Improving Web Application Security, Threats and Countermeasures, patterns & practices, Microsoft Corpor-
ation, 2003
Page 4 /15

Emanuela Boroș

Category Description Threats
Input validation refers to how your Buffer overflow; cross-
application filters, scrubs, or rejects site scripting; SQL
Input Validation
input before additional processing. injection

Authentication is the process that an Network eavesdropping;
entity uses to identify another entity, brute force attacks;
Authentication
typically through credentials such as dictionary attacks; cookie
a user name and password. replay; credential theft

Authorization is the process that an Elevation of privilege;
application uses to control access to disclosure of confidential
Authorization
resources and operations. data; data tampering;
luring attacks

Unauthorized access to
administration interfaces
Configuration Configuration management refers to
and to configuration
how your application handles
Management stores; overprivileged
operational issues.
process and service
accounts

Sensitive data is information that Access sensitive data in
must be protected either in memory, storage; network
Sensitive Data
over the wire, or in persistent stores. eavesdropping; data
Your application must have a tampering
process for handling sensitive data.

A session refers to a series of related Session hijacking; session
interactions between a user and your replay; man in the middle
Session
Web application. Session
Management
management refers to how your
application handles and protects
these interactions.

Cryptography refers to how your Poor key generation or
application enforces confidentiality key management; weak
Cryptography
and integrity. or custom encryption

Form fields, query string arguments, Query string
and cookie values are frequently manipulation; form field
Parameter
used as parameters for your manipulation; cookie
Manipulation application. Parameter manipulation manipulation; HTTP
refers to both how your application header manipulation
safeguards tampering of these values
and how your application processes
input parameters.

Exception When a method call in your Information disclosure;
application fails, what does your denial of service
Management
application do? How much does it
reveal about the failure condition?

Auditing and Auditing and logging refer to how User denies performing
your application records security- an operation; attacker
Logging
related events. exploits an application
without trace; attacker
covers his or her tracks

Page 5 /15

Emanuela Boroș

Web application vulnerabilities are easy to exploit with a variety of attack techniques and
tools. When vulnerabilities are broken down by category, some interesting trends begin
to emerge. Cross-Site Scripting (XSS) and SQL Injection (SQLi) still comprise the
most significant amount of new Web application vulnerability disclosures 10. XSS is
commonly used for spam, phishing, and Web browser exploits. Buffer Overflow and
Denial of Service (DoS) vulnerabilities round out the top four.

It is interesting to note that the breakdown of popular vulnerabilities by category remains
fairly consistent over the past three years, likely because XSS vulnerabilities are
relatively easy to find and are very useful to attackers. Spammers and phishers are always
looking for ways to make their trade more profitable, and XSS continues to be a useful
vulnerability for these purposes.

a) Input Validation

Input validation is a security issue if an attacker discovers that your application makes
unfounded assumptions about the type, length, format, or range of input data. The
attacker can then supply carefully crafted input that compromises your application. When
network and host level entry points are fully secured; the public interfaces exposed by
your application become the only source of attack. The input to your application is a
means to both test your system and a way to execute code on an attacker’s behalf. Does
your application blindly trust input? If it does, your application may be susceptible to the
following11:
SQL injection
Buffer overflows
Cross-site scripting

10 The 2011 Mid-Year Top Cyber Security Risks Report http://h20195.www2.hp.com/v2/GetPDF.aspx/4AA3-
7045ENW.pdf, pg.6
11 Improving Web Application Security, Threats and Countermeasures, patterns & practices, Microsoft Corpor-
ation, 200, Chapter 2: Threats and Countermeasures, pg. 25-26
Page 6 /15

Emanuela Boroș

3. SQL Injection

Web applications are affected by multiple types of attacks, and SQLi and XSS are just
two that have received a significant amount of media attention over the last few months.
SQL injection is a vulnerability that allows an attacker to alter backend SQL statements
by manipulating the user input. An SQL injection occurs when web applications accept
user input that is directly placed into a SQL statement and doesn't properly filter out
dangerous characters.
This is one of the most common application layer attacks currently being used on the
Internet. Despite the fact that it is relatively easy to protect against, there is a large
number of web applications vulnerable.
An attacker may execute arbitrary SQL statements on the vulnerable system. This may
compromise the integrity of your database and/or expose sensitive information.
Depending on the back-end database in use, SQL injection vulnerabilities lead to varying
levels of data/system access for the attacker. It may be possible to not only manipulate
existing queries, but to UNION in arbitrary data, use subselects, or append additional
queries. In some cases, it may be possible to read in or write out to files, or to execute
shell commands on the underlying operating system. Certain SQL Servers such as
Microsoft SQL Server contain stored and extended procedures (database server
functions). If an attacker can obtain access to these procedures it may be possible to
compromise the entire machine.

a) State-of-the-art

SQL Injection is an attack technique used to exploit applications that construct SQL
statements from user-supplied input. When successful, the attacker is able to change the
logic of SQL statements executed against the database.
Structured Query Language (SQL) is a specialized programming language for sending
queries to databases. The SQL programming language is both an ANSI and an ISO
standard, though many database products supporting SQL do so with proprietary
extensions to the standard language. Applications often use user-supplied data to create
SQL statements. If an application fails to properly construct SQL statements it is possible
for an attacker to alter the statement structure and execute unplanned and potentially
hostile commands. When such commands are executed, they do so under the context of
the user specified by the application executing the statement. This capability allows
attackers to gain control of all database resources accessible by that user, up to and
including the ability to execute commands on the hosting system.
This is how SQLi attacks have evolved over the years:
1998 – Rain Forest Puppy (RFP) discloses/discusses the initial idea of SQL
Injection in Phrack Magazine (Volume 9, Issue 54)
2000 – SQL Injection FAQ – Chip Andrews – uses the first public usage of term
“SQL Injection” in a paper
2003 – The idea of blind SQL Injection is disclosed/discussed
2006 – Web application vulnerability disclosure skyrockets in part due to SQL
Injection
2008 – SQL Injection vulnerability disclosure peaks

Page 7 /15

Emanuela Boroș

2008 – The Asprox botnet leverages SQL Injection for mass drive by SQLi
attacks to grow botnet (http://en.wikipedia.org/wiki/Asprox). From at least April
through August, a sweep of attacks began exploiting the SQL Injection vulnerabilities
of Microsoft's IIS Web server and SQL Server database server. The attack does not
require guessing the name of a table or column, and it corrupts all text columns in all
tables in a single request. An HTML string that references a malware JavaScript file is
appended to each value. When that database value is later displayed to a website visitor,
the script attempts several approaches at gaining control over a visitor's system. The
number of exploited Web pages is estimated at 500,000.
On August 17, 2009, the U.S. Justice Department charged an American citizen
Albert Gonzalez and two unnamed Russians with the theft of 130 million credit card
numbers using a SQL Injection attack. In reportedly “the biggest case of identity theft in
American history,” the man stole cards from a number of corporate victims after
researching their payment processing systems. Among the companies hit were credit
card processor Heartland Payment Systems, convenience store chain 7-Eleven, and
supermarket chain Hannaford Brothers.
On February 5, 2011, HBGary, a technology security firm, was broken into by
Anonymous using a SQL Injection in their CMS-driven website.
On April 11, 2011, Barracuda Networks was compromised using a SQL
Injection flaw. Email addresses and usernames of employees were among the
information obtained.
On June 1, 2011, “hacktivists” of the group LulzSec were accused of using SQLi
to steal coupons and to download keys and passwords that were stored in plaintext
on Sony's website, accessing the personal information of a million users.
In June 2011, Group Anonymous claims to have hacked the NATO site, using a
“simple SQL Injection”. With SQLi attacks, it is readily apparent that attackers are
content leveraging existing vulnerabilities for their exploits.

b) SQL Injection Example
1. use of string concatenation to build query: SQL Injection can happen with dynamic
database queries concatenated with user supplied input, for example with the
following query:

"SELECT * FROM tableName WHERE name =" + parameter;"

2. if the user supplies "name' OR 'a'='a' " as the parameter it results in the following:

"SELECT * FROM tableName WHERE name ='name' OR
'a'='a';"

3. the OR 'a'='a' causes the where clause to always be true which is the equivalent of
the following:
"SELECT * FROM tableName;"

Page 8 /15

Emanuela Boroș

4. if the user supplies "name' OR 'a'='a' ; DELETE FROM tableName" as the
parameter it results in the following:

"SELECT * FROM tableName WHERE name ='name' OR 'a'='a';
DELETE FROM tableName;"

5. the OR 'a'='a' causes the WHERE clause to always be true which is the equivalent
of the following:

"SELECT * FROM tableName; DELETE FROM tableName;"

6. some database servers, allow multiple SQL statements separated by semicolons to
be executed at once.

c) Protecting against SQL Injection

SQL Injection arises from an attacker's manipulation of query data to modify query logic.
The best method of preventing SQL Injection attacks is, therefore, to separate the logic of
a query from its data; this will prevent commands inserted from user input from being
executed. The downside of this approach is that it can have an impact on performance
and that each query on the site must be structured in this method for it to be completely
effective. If one query is inadvertently bypassed, that could be enough to leave the
application vulnerable to SQL Injection.
These are some tips in order to protect your system from SQL injection:
Don't concatenate user input data to a query or command
Use Query Parameter binding with typed parameters, this ensures the input data
can only be interpreted as the value for the intended parameter so the attacker can
not change the intent of a query
Validate all input data to the application using white list (what is allowed) for
type, format, length, range, reject if invalid
Don't provide too much information in error messages (like SQL Exception
Information, table names) to the user.

Page 9 /15

Emanuela Boroș

The following code shows a sample SQL statement that is SQL injectable.
sqlStatement = "SELECT * FROM tableName";
sqlStatement = sqlStatement + "WHERE id =" + id;
oCmd.CommandText = sqlStatement;

The following example utilizes parameterized queries and is safe from SQL Injection
attacks.
sqlStatement = "SELECT * FROM tableName";
sqlStatement = sqlStatement + "WHERE id = id;
oCmd.CommandText = sqlStatement;
oCmd.Parameters.Add("id", id);

The application will send the SQL statement to the server without including the user's
input. Instead, a parameter – id – is used as a placeholder for that input. In this way, user
input never becomes part of the command that SQL executes. Any input that an attacker
inserts will be effectively negated. An error would still be generated, but it would be a
simple data-type conversion error, and not something that a hacker could exploit.

d) Java specific Protecting against SQL Injection

4. Don't concatenate user input data to a query or command:

Don't do this with JDBC:

String id = req.getParameter("id");
String query = "SELECT * FROM tableName WHERE id = '" +
id +"'";

Don't do this with JPA:

query = entityManager.createQuery("SELECT * FROM
tableName t WHERE " + "t.id = '" + id + "'");

Page 10 /15

Emanuela Boroș

5. Use Query Parameter binding with typed parameters

With JDBC you should use a PreparedStatement and set values by calling one of the
setXXX methods on the PreparedStatement object

String sql = "SELECT * FROM tableName WHERE id = ? ";
PreparedStatement pStmt = con.prepareStatement(sql);
pStmt.setString(1, id);

This sets the first question mark placeholder to the value of the input parameter id in the
SQL command. Any dangerous characters – such as semicolons, quotes, etc.. should be
automatically escaped by the JDBC driver.
With JPA or Hibernate you should use Named Parameters. Named parameters are
parameters in a query that are prefixed with a colon (:). Named parameters in a query
are bound to an argument by the javax.persistence.Query.setParameter(String name,
Object value) method. For example:

query = entityManager.createQuery(
"SELECT e FROM tableName t WHERE " + "t.id = ':id'");
q.setParameter("id", id);

This sets the id to the id in the SQL command, again any dangerous characters should
be automatically escaped by the JDBC driver.
With JPA 2.0 or Hibernate you can use the Criteria API. The JPA 2.0 criteria API
providies a typesafe object-based Query API based on a metamodel of the Entity
classes, rather than a string-based Query API. This allows you to develop queries that a
Java compiler can verify for correctness at compile time. Below is an example using the
Criteria API for the same query as before :
QueryBuilder qb = em.getQueryBuilder();
CriteriaQuery<Employee> q =
qb.createQuery(TableName.class);
Root<TableName> t = q.from(TableName .class);
ParameterExpression<String> id =
cb.parameter(String.class);

TypedQuery<TableName> query = em.createQuery(
q.select(t).where(cb.equal(t.get(TableName_.id), id) );
query.setParameter(“id”, id);

6. SQL Injection Scanners

a) Pangolin

Pangolin is an automatic SQL injection penetration testing tool developed by NOSEC.
Its goal is to detect and take advantage of SQL injection vulnerabilities on web
applications. Once it detects one or more SQL injections on the target host, the user can
choose among a variety of options to perform an extensive back-end database
management system fingerprint, retrieve DBMS session user and database, enumerate
users, password hashes, privileges, databases, dump entire or user’s specific DBMS
tables/columns, run his own SQL statement, read specific files on the file system and
more.

Page 11 /15

Emanuela Boroș

1. Database Support

Access: (Database Path; Root Path; Drivers); Data
MSSql: Data; FileReader; RegReader; FileWriter; Cmd; DirTree
MySql: Data; FileReader; FileWriter
Oracle: Version; IP; Database; Accounts, Data
DB2: Data
Sybase: Data
PostgreSQL: Data; FileReader
Sqlite: Data
At present, most of the functions are directed at MSSQL and MySql coupled with
Oracle and Access. Other small and medium-sized companies are using DB2, Sybase,
PostgreSQL, as well as Sqlite which isn't so common.

2. Sample use of Pangolin

Run Pangolin then type or paste the URL that you suspect is susceptible to SQL
injection.

Page 12 /15

Emanuela Boroș

Page 13 /15

Emanuela Boroș

b) GreenSQL

GreenSQL is a Database Security solution. GreenSQL is an Open Source database
firewall used to protect databases from SQL injection attacks. It works as a proxy and
has built in support for MySQL and PostgreSQL. The logic is based on evaluation of
SQL commands using a risk scoring matrix as well as blocking known db
administrative commands (DROP, CREATE, etc).
Sample page protected by GreenSql at http://www.greensql.net/sql-injection-test

Page 14 /15

Emanuela Boroș

c) Add-ons for Firefox

Security Compass with:

1. SQL Inject Me

SQL Injection vulnerabilities can cause a lot of damage to a web application. A
malicious user can possibly view records, delete records, drop tables or gain access to
your server. SQL Inject-Me is Firefox Extension used to test for SQL Injection
vulnerabilities (not available for Firefox 8.0).

7. Bibliography

[The 2011 Mid-Year Top Cyber Security Risks Report, Article, HP DVLabs, HP teams: Fortify
and the Application Security Center, Hewlett-Packard Development Company, L.P, September
2011, http://h20195.www2.hp.com/v2/GetPDF.aspx/4AA3-7045ENW.pdf]
[Open Web Application Security Project (OWASP), OWASP Foundation, last modified on 11
October 2011, https://www.owasp.org/]
[Java.net, 2011, Oracle, http://weblogs.java.net/blog/caroljmcdonald/archive/2009/10/02/top-
10-web-security-vulnerabilities-number-2-injection-flaws]
[SANS Information Security & Research, SANS Institute, September 2009,
http://www.sans.org/top-cyber-security-risks/]
[Acunetix, Acunetix Web Vulnerability Scanner, 2011, http://www.acunetix.com/blog/web-
security-zone/articles/sql-injection-prevalent-hack/]
[Open Source Vulnerability Database (OSVDB), 2011, http://osvdb.org/]
[Improving Web Application Security, Threats and Countermeasures, patterns & practices,
Microsoft Corporation, Microsoft Corporation, 2003, http://msdn.microsoft.com/en-
us/library/ff649874.aspx]

Page 15 /15

Software Security - Vulnerability&Attack

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (17)

Andere mochten auch

Andere mochten auch (17)

Ähnlich wie Software Security - Vulnerability&Attack

Ähnlich wie Software Security - Vulnerability&Attack (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Software Security - Vulnerability&Attack