Securing Web Application Code by Static Analysis and Runtime Protection

greenpepperwhinnySecurity

Nov 3, 2013 (3 years and 8 months ago)

73 views





VISHAL KUMAR

Securing Web Application Code by

Static Analysis and Runtime Protection

CONTENTS
:


Cross
-
Site Scripting (XSS)


SQL Injection


General Script Injection


Modeling Web Application Vulnerabilities


Type
-
Based Analysis


Dataflow Analysis


Static Checking


Runtime Protection


Conclusion

1. INTRODUCTION


WEB APPLICATION VULNERABILITIES


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


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.




Example of a Cross Site Scripting attack

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




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

WEB APPLICATION VULNERABILITIES


1.
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
:


var

Shipcity
;

ShipCity

=

Request
.
form

("
ShipCity
")
;

var

sql

=

"select

*

from

OrdersTable

where

ShipCity

=

'"

+

ShipCity

+

"'"
;


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
--
'





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
.

SQL Injection:

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.

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
');





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

Modeling Web Application Vulnerabilities:

Modeling Web Application Vulnerabilities:

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





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
.

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
.

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.

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.




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/






Thank You…