The Case of Promiscuous
Parameters and Other Ongoing
Mysteries in Web Security
AppSec DC
The OWASP Foundation
http://www.owasp.org
Jacob West
Director, Security Research
and Engineering Services
Fortify Software
OWASP
Today's Evolutionary Mysteries
I. Promiscuous Parameters III. Licentious Listeners
register_globals
– gets(), operator >>
Struts 2, Spring MVC
– readLine()
II. Wanton Web Data
Cross-Site Scripting
JavaScript Hijacking
IV. Deleterious Delvers
– addslashes()
– <c:out/>,
.NET Validation Framework
OWASP
3
MYSTERY I
PROMISCUOUS PARAMETERS
OWASP
4
Promiscuous Parameters:
When a platform or
framework makes it too easy
to access HTTP request
parameters, it blurs the line
between trusted and
untrusted data and can leave
programs open to attack
OWASP
5
PHP register_globals




Injects request parameters as global variables
Most infamous cause of PHP's bad security mojo
"The" input paradigm in PHP until version 4.2.0
Deprecated in PHP 5.3.0; Removed in 6.0.0
OWASP
6
Example: register_globals
 Attackers can override server-side values
Attacker’s Request
authorized = true
<?php//
// $authorized = true for authenticated users
if (authenticated_user()) {
$authorized = true;
}
if ($authorized) {
include "/highly/sensitive/data.php";
}
?>
OWASP
7
Fast Forward to 2008
 Struts 2
Introduces flexible POJO
beans and actions
Automatically maps
request parameters to
POJO fields
 Spring MVC
Provides similarly
"friendly” functionality
for mapping request
parameters in to
command beans
OWASP
8
Example: Struts 2 Action
 Struts 2 permits the same behavior
...
Attacker’s Request
authenticated = true
public String execute() throws Exception {
if (authenticated || DB.isValid(user, pass)){
authenticated = true;
return SUCCESS; // keys to the kingdom
}
return FAILURE;
}
...
OWASP
9
Promiscuous Parameters
 Antipattern: Blurring trust boundaries and quiet input
 Same old "convenience" over "security" tradeoff
 Old or new, this vulnerability
 Makes input validation hard to apply consistently
 Handicaps automated approaches to verifying security
 Represents a regression
 Globally for Java
 Specifically for Struts (from 1 to 2)
OWASP
10
MYSTERY II
WANTON WEB DATA
OWASP
11
Wanton Web Data: Nothing good comes from mixing code and
data; the two mixing is at the root of many serious security
vulnerabilities and yet we insist on repeating the mistakes of our
past again and again
The Dark Side of Ajax
OWASP
12
Example: Cross-Site Scripting
<c:if test="${param.sayHello}">
Hello ${param.name}!
</c:if>
“We never intended the code that's
in there to actually be productionready code.”
- Ryan Asleson
OWASP
13
Reliving Past Mistakes
 Cross-site scripting looks more and more like
buffer overflow
Buffer Overflow




Allows arbitrary code execution
Easy mistake to make in C/C++
Exploit is hard to write
Well known problem for decades
Cross-Site Scripting




Allows arbitrary code execution
Easy mistake to make
Exploit is easy to write
Well known problem for a decade
OWASP
14
What About Ajax?
 Today’s rage or tomorrow’s security disaster?
 Could more JavaScript possibly be better?
 Sample of the almost 400 JavaScript CVE entries:
CVE-2007-1794: The Javascript engine in Mozilla 1.7 and earlier… can
allow remote attackers to execute arbitrary code.
CVE-1999-0793: Internet Explorer allows remote attackers to read files
by redirecting data to a Javascript applet.
CVE-1999-0790: A remote attacker can read from a Netscape user's
cache via JS
CVE-1999-0347: Internet Explorer 4.01 allows remote attackers to read
local files and spoof web pages via a "%01" character
in an "about:" Javascript URL, which causes Internet
Explorer to use the domain specified
OWASP
15
Ajax - The Case of the Vanishing “X”
 JavaScript/JSON is gradually replacing XML
XML
<book>
<title>JavaScript, the Definitive Guide</title>
<publisher>O'Reilly</publisher>
<author>David Flanagan</author>
<cover src="/images/cover_defguide.jpg" />
<blurb>elit.</blurb>
</book>
{ "book": {
"title":"JavaScript, the Definitive Guide",
"publisher":"O'Reilly",
"author":"David Flanagan",
JSON
"cover":"/images/cover_defguide.jpg",
"blurb":”elit.”
}
}
OWASP
Old: Cross-Site Request Forgery (CSRF)
 Cross-Site Request Forgery
JavaScript submits HTTP requests on victim's behalf
Allows attackers’ malicious JavaScript to submit
commands, but not inspect the response per the Same
Origin Policy (SOP)
Attack against data integrity
 Application is vulnerable if it:
1.Relies on user’s identity
(e.g. persistent or session cookies)
2.Does not have a secondary authentication mechanism
OWASP
17
New: JavaScript Hijacking - 1/2
Ajax Application
Malicious Server
GET
1) "show me dancing pigs!"
2) "check this out"
{ witness code }
<script src="…">
3) confidential data
JavaScript
Vulnerable
Browser
OWASP
18
New: JavaScript Hijacking - 2/2
 Builds on CSRF
 Breaks confidentiality through loophole in SOP
 Vulnerable if:
1. Site responds to HTTP GET
and
2. Transmits sensitive data in JavaScript syntax
OWASP
19
Defenses Against JavaScript Hijacking
 Prevent CSRF
Decline malicious requests by requiring unique token
… and remember
 Default to POST not enough
(Developers add GET so that result can be cached)
 Check for a known HTTP header not enough
(Flash CSRF vulnerability)
and
 Prevent direct execution of JSON as JavaScript
while(1);, /* ... */, etc
… and remember
 calling parseJSON() rather than eval() does not help
OWASP
20
Wanton Web Data
 Antipattern: Mixing code and data fluidly
 Mixing code and data is never a good idea
 Old or new, this vulnerability
Makes it hard for programmers to code securely
because the convention is based on insecure practices
Represents a regression
 XML is designed to represent and transport data
OWASP
21
MYSTERY III
LICENSTIOUS LISTENERS
OWASP
22
Licentious Listeners:
Programs must accept
input, but if they accept
too much it can
squander resources and
bring the system to its
knees
OWASP
Rosetta Stone
 A single story translated across languages
Egyptian Hieroglyphics
Egyptian Demotic
Classical Greek
 A single vulnerability translated across
languages
C
C++
Java
.NET and beyond
OWASP
24
A Vulnerability Rosetta Stone
 Oldest trick in the book:
char buf[128];
gets(buf);
 At runtime:
warning: this program uses gets(),
which is unsafe.
(1 of 4 vulnerabilities exploited by the Morris Worm)
OWASP
25
A Vulnerability Rosetta Stone
 C++:
char buf[128];
cin >> buf;
 At runtime:
(silence)
OWASP
26
A Vulnerability Rosetta Stone
 Improvement? C++:
string str;
cin >> str;
 How much data is read?
 How much data do you have?
OWASP
27
A Vulnerability Rosetta Stone
 Now Java:
String str;
str = bufferedReader.readLine();
 How much data is read?
 How much data do you have?
OWASP
28
Licentious Listeners
 Antipattern: Reading unbounded input
 Just because an attacker can't execute code
doesn't mean they can't compromise availability
 Old or new, this vulnerability
Is destined to be repeated again and again
Favors ease of use over controlled behavior and
security
Is an unfortunate holdover that hasn't been fixed
OWASP
29
MYSERT IV
DELETERIOUS DELVERS
OWASP
30
Deleterious Delvers: Input
validation based on blacklisting
can lead to a false sense of
security, which is sometimes more
dangerous than no security at all
OWASP
31
PHP magic_quotes_gpc
 Runs addslashes() on values from GET,
POST, and COOKIE
 Escapes the following SQL meta characters:
single quotes ('), double quotes ("), null bytes
(NULL), and backslashes (\) using a backslash
(single quote for ' if magic_quotes_sybase is
true)
 Fails to prevent SQL injection in some cases;
does nothing for other characters (e.g. XSS, etc)
 Deprecated in PHP 5.3.0; removed in PHP 6.0.0
OWASP
32
Example: magic_quotes_gpc
 Queries that expect to include un-quoted, nonstring variables are trivially vulnerable
$id = $_POST['userId'];
mysql_query("SELECT * FROM usr WHERE id={$id}");
 Queries that use LIKE are vulnerable to attacks
using % and _
$sub = $_POST['subject'];
mysql_query("SELECT * FROM msg WHERE subject \
LIKE '{$sub}%'":);
OWASP
33
Fast Forward
 Sun JSTL
<c:out> tag applies
XML encoding by default
 Microsoft .NET
Framework
Validation framework
uses blacklisting on
incoming request
parameters and some
output values
OWASP
34
Example: Context is King
 XML encoding is sufficient in some contexts:
<html>
Your address is <c:out value="${sender}"/>
</html>
 … and insufficient in others:
<script>
alert(Your address is <c:out value="${sender}"/>);
</script>
OWASP
35
Deleterious Delvers
 Antipattern: Blacklisting input and output
 "too good to be true”; input validation is hard
 Old or new, this vulnerability
Leads to a false sense of confidence in security
Blurs the line between trusted and untrusted
Makes it less likely that good input validation mechanisms
will be built
OWASP
36
LEARNING FROM
PAST MISTAKES
OWASP
37
A Look to the Future of Web Security
1.
2.
3.
4.
Better web standards
Frameworks must build security in
Better automated analysis
Security in the development lifecycle
OWASP
38
1. Better Web Standards
 Cookies – Broken
Need working HTTP only cookies
 Browsers – Broken
Need to distinguish code from different domains
Need to make it easier to distinguish code and data
 Collin Jackson, Stanford
(http://www.collinjackson.com/)
OWASP
39
2. Frameworks Must Build Security In
 Provide secure defaults
 Built-in security features
Prevent CSRF / JavaScript Hijacking out-of-the-box
Basis for input validation framework
 Opportunity for better validation
Better separation between display and controller
Better definition for browser/server interaction
 New frameworks making progress (e.g. Adobe)
Documented security best-practices
Hard to mistake data and code
Well-defined system for cross-domain communication
OWASP
40
3. Better Automated Analysis
 Investigate customization
Map tool against security standards in symbiotic way
 Software more amenable to automated analysis
Building blocks follow the same advice (frameworks)
Security must trump usability in some case
 Leverage dynamic techniques to prioritize effort
OWASP
41
4. Security in the Development Lifecycle
OWASP
42
Parting Thoughts
 Security problems everywhere you look
Languages, libraries,
frameworks, etc.
 Right answer
Better languages,
libraries, frameworks
Conventions
Data
Structures
Algorithms
Design
Protocols
<Your Code>
 Realistic answer
Build secure programs
out of insecure pieces
Libraries
Platform
Language
OWASP
43
Questions?
jacob@fortify.com
AppSec DC
The OWASP Foundation
http://www.owasp.org