DEV meet-up UiPath Document Understanding May 7 2024 Amsterdam
2 Roads to Redemption - Thoughts on XSS and SQLIA
1. 2 Roads to Redemption
Thoughts on fixing SQLIA and XSS
Florian Thiel,
TU Berlin, 12/16/2008
florian.thiel ät noroute.de
2. Source: OWASP (Open Web Application Security Project)
works on awareness and best practices for WAS. Open approach.
based on MITRE Vulnerability Trends 2006
- biased a little, not based on a controlled population (various research bodies)
I will talk about the first two. OWASP differentiates between XSS and injection flaws (such as
SQLIA) but I’ll show you that they have much in common.
The two vulnerabilities are very common and high-profile websites have been attacked.
I’ll explain the background and than what I’m going to do about it.
3. OWASP Top 10 2007
1. XSS
2. Injection Flaws
3. Malicious File Execution
4. Insecure Direct Object Reference
5. Cross-Site Request Forgery
Source: OWASP (Open Web Application Security Project)
works on awareness and best practices for WAS. Open approach.
based on MITRE Vulnerability Trends 2006
- biased a little, not based on a controlled population (various research bodies)
I will talk about the first two. OWASP differentiates between XSS and injection flaws (such as
SQLIA) but I’ll show you that they have much in common.
The two vulnerabilities are very common and high-profile websites have been attacked.
I’ll explain the background and than what I’m going to do about it.
4. OWASP Top 10 2007
1. XSS
2. Injection Flaws
3. Malicious File Execution
4. Insecure Direct Object Reference
5. Cross-Site Request Forgery
Source: OWASP (Open Web Application Security Project)
works on awareness and best practices for WAS. Open approach.
based on MITRE Vulnerability Trends 2006
- biased a little, not based on a controlled population (various research bodies)
I will talk about the first two. OWASP differentiates between XSS and injection flaws (such as
SQLIA) but I’ll show you that they have much in common.
The two vulnerabilities are very common and high-profile websites have been attacked.
I’ll explain the background and than what I’m going to do about it.
10. XSS. Infamous with PHP due to it’s origins. Not so much cross-site today...
11. “This issue isn't just about scripting, and
there isn't necessarily anything cross site
about it. So why the name? It was coined
earlier on when the problem was less
understood, and it stuck. Believe me, we have
had more important things to do than think
of a better name. <g>. “
-- Marc Slemko, Apache.org
The real problem is getting code included in a web page so that it is interpreted by the web
browser. Cross-site comes from frames, popular in 1996, include() in PHP
12. XSS SQLIA
eval(‘user input’)1,2
1) the essence of injections
2) limited only by the execution environment
The common root of the two problems is that you basically eval user input. In XSS, you do
this directly (aka ‘by design’) in SQL this is a matter of missing sophistication in app design.
13. Failure to sanitize data
into a different plane
This is the weakness that actually appears in apps. Common Weakness Enumeration
What’s perfectly fine in one plane might not be in the other one. Injecting SQL via XSS does
no harm (because the browser cannot make sense of it).
For SQL: From User Input or HTML to SQL Engine
For XSS: From HTML, Strings to Web Browser (HTML, JS, Flash, ... engine)
14. technical non-solutions
• addslashes() or any one-size-fits-all
• blacklisting (IPS, validation, etc.)
PHP: numeric field (no quotes) and encoding
IDS: char(114,111,111,116) (“root” (in MySQL))
white spaces, or for 1=1: do “something” = “some”+”thing”
15. technical solutions
• AntiSamy
• ReForm
• prepared statements
• Safe Query Objects
• ...
AntiSamy from OWASP, interesting project, supplies “profiles” for pages that need some
markup. ReForm is a standard library by OWASP again, escapes HTML in a defined way,
multiple languages.
Safe Query Objects are an extension of the prepared statements idea, adds types. Makes
constraint checking possible.
Looks good!
16. only half-way there
technical solutions become more and more sophisticated. There’s light at the end of the
tunnel, but...
17. WP MU < 2.6 XSS
“In /wp-admin/wpmu-blogs.php an attacker can
inject javascript code, the input variables quot;squot; and
quot;ip_addressquot; of GET method aren't properly
sanitized.”
--[Full-disclosure], Sept 2008
This is just an example. Recent WP exploit. Nothing to do with missing technology. Failure to
do sanitation correctly.
18. WP MU < 2.6 XSS
“In /wp-admin/wpmu-blogs.php an attacker can
inject javascript code, the input variables quot;squot; and
quot;ip_addressquot; of GET method aren't properly
sanitized.”
--[Full-disclosure], Sept 2008
This is just an example. Recent WP exploit. Nothing to do with missing technology. Failure to
do sanitation correctly.
19. ey ’re
er e. Th t!
a re h ye Gibson
ed illiam
io ns ut ing W
rib hras
solut istparap
d --
e
Th ot eve nly
j ustn
William Gibson knew it: We got the techniques, but not everybody is aware of it. Not evenly
distributed yet, heh? So, let’s talk about approaches how to get there and the interesting part
(tm)
20. The interesting* part
* what my thesis is really about
This part is shorter and has less data, more fuzzy assumptions.
21. Developers more Code
I see two roads to go from here. The first one is to educate developers and make it easier for
them to use the future/the tools. Reduce oversight!
The second one is a technical solution. Write code that takes care of correct application of
measures.
Common to both: Take away some cognitive load from the developers.
22. Helping developers
• raise awareness
• facilitate detection/motivate reviews
• motivate repair
awareness: “You wouldn’t recognize iambic pentameter if it bit you on the butt”. We need
patterns to find vulnerabilities. (There are broken examples in the wild, many books have
them) But: developers have to be constantly aware of the critical spots in their code. That’s
where annotations come in.
Mark the spots that directly interact with user input, add rich annotations to tell the
developer of his/her surroundings.
Facilitate detection: If you annotate critical spots you’ll find inconsistencies easier. Add
annotations gives you extra value for reviews, turns up in VC.
Motivate repair: annotations may show you how many critical sections you have in your code.
Tool support will make you embarassed!
23. // @userinput(data,source=”webform”,
// type=”username”)
// [insert data into query, ignore
// non-alphanums]
def insertAlphaNum(query, data):
// [make sure data is
canonical]
c_data = data.toCharSet(...)
c_data.replace(...)
...
// [insert data into query]
// @output(target=sql,
// type=”username”)
query.prepare(...)
query.insert(data...)
...
An example:
the @userinput annotation says that data is from userinput and comes from a webform. The
idea is to spread knowledge about the data out in the sourcecode. You usually have to know
know more about data than its type (it’s “string”, anyway.
This can also provide support for tooling in the future. The [] part comes from structured
programming. We want to have a light-weight “proof” for code sections. The idea is stepwise
abstraction. look at what the innermost annotation says and check the (less than 10) lines of
code. Then you can use the abstraction given in the annotation as the effect of the code. The
idea is to keep mental load low.
Also, this facilitates reuse. If you change a part of code, you only have to see if the
surrounding annotation still holds.
If you’re constructing code, you can use this the other way round. Give the effect of the
outermost annotation, write the next abstraction refinement, prove this, refine further, etc.
This is used in Cleanroom software development, which has a really good track record for
defect-free software.
24. What do you use to
communicate critical sections?
Audience participation: How many of you work in a multi-person project? How do you tell
your colleagues about critical sections? Documentation? Annotations? Do you have a technical
solution?
25. Would you use annotations?
Your requirements?
Does this annotation thing make sense to you? Would you use it? How easy would it have to
be? What functions would you like?
I promised you another approach. Let’s just motivate this a bit...
26. GET /en-us/library/aa287673(VS.71).aspx HTTP/1.1
Host: msdn.microsoft.com
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:
1.9.0.3) Gecko/2008092414 Firefox/3.0.3
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
Connection: keep-alive
Referer: http://www.google.de/search?q=http+request+header
+example&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-
US:official&client=firefox-a
Cache-Control: max-age=0
This is the zoo!
there are many sources of potential user input. Basically everything that is external to the
system.
HTTP Header parameters (anyone know exploits for the Referer? I would expect some for ad
companies :-)
Cookies (the cookie monster didn’t know, but cookies can be evil)
Environment variables (maybe)
Forms
We have to trace EVERY SINGLE occurrence of user input! -> Flow analysis
Tainting functionality only takes us so far. String-based taint is missing granularity.
Character-based tainting is better but still cannot determine if the programmer is doing the
right thing.
Oh, and types. We still need the programmer to decide on sensible types for EVERY SINGLE
input value and implement the sanitation correctly.
27. This is the zoo!
there are many sources of potential user input. Basically everything that is external to the
system.
HTTP Header parameters (anyone know exploits for the Referer? I would expect some for ad
companies :-)
Cookies (the cookie monster didn’t know, but cookies can be evil)
Environment variables (maybe)
Forms
We have to trace EVERY SINGLE occurrence of user input! -> Flow analysis
Tainting functionality only takes us so far. String-based taint is missing granularity.
Character-based tainting is better but still cannot determine if the programmer is doing the
right thing.
Oh, and types. We still need the programmer to decide on sensible types for EVERY SINGLE
input value and implement the sanitation correctly.
28. Current approaches
• global XSS filter (HTML escapes) on/off
• default sanitation of all data
That’s how it’s done currently. E.g. Code Igniter, PHP framework or Django, Python. Global
sanitation does not allow for some markup. It does not address the SQLIA problem, too.
There are SQLIA attacks that rely on the differing execution context of the validator and the
DB.
29. Current approaches
g h !
n u
o on/off
• e
ledata
global XSS filter (HTML escapes)
b
• default sanitationiof all
x
t fl e
N o
That’s how it’s done currently. E.g. Code Igniter, PHP framework or Django, Python. Global
sanitation does not allow for some markup. It does not address the SQLIA problem, too.
There are SQLIA attacks that rely on the differing execution context of the validator and the
DB.
30. Helping the framework
• machines are good at doing repetitive
work!
• if they just knew enough...
OK, the other approach. Why let humans do what machines are best at? Oh, they don’t know
enough to be good enough.
31. Rich Types
Let’s educate the framework. If we had semantic types that could do more than naïve
operations.
32. Rich Types
• if we had a “firstname” type
• and one for “XML”
• and one for a “ebay-style post”
Let’s educate the framework. If we had semantic types that could do more than naïve
operations.
33. Rich Types
• if we had a “firstname” type
• and one for “XML”
• and one for a “ebay-style post”
• we could do flexible validation/sanitation
Let’s educate the framework. If we had semantic types that could do more than naïve
operations.
34. What we’d get
• Types for SQL prepared statements
• Types for AntiSamy/Template engine
• Types for future backends
• Types/Constraints for forms (XForms?)
• rich constraints on complex types
We could use something like Safe Query Objects because we knew enough.
We could automatically use AntiSamy without custom profile specifications.
We could do rich validation in forms, maybe XForms engines.
We could have internal constraints on types, maybe good for overall system security.
35. How it’d look like
class MyTextField(models.Field):
# may only contain <H1>
sqlserializer = SQLFilter(type=”html”) # to SQL
htmlserializer = AntiSamy(“H1Profile”) # to HTML
validator = HtmlValidator(tagsAllowed=(“h1”))
This is a very simple example. A textfield that should only contain <H1>s. SQL Serializer can
take care of charset conversion (encode everything).
htmlserializer only lets H1s through.
Validator can make sure that input is valid HTML (all characters are encoded).
There is some redundancy, but that’s good for security, right?
36. Drawbacks
• needs decent infrastructure form
framework
• needs good type catalogue to be easy
enough to use
• what about HTTP headers, cookies?
• simpler approaches available (Django)
We would need quite a heavyweight frameworks were we could attach validators/filters/
whatever to all data interactions.
Nobody would use it if the default types were not covered. Maybe create a public catalogue
usable in different languages. Central updates
To be consistens, HTTP Headers and Cookies would need types. As long as applications don’t
do crazy things, we could think up a generic type for that...
There’s Django: They don’t allow any HTML and stuff. Use RST, Textile, Markdown instead.
You have to explicitly say if you want something not htmlescaped. Secure by default.
Benefits for Django:
- Better form validation
- internal type checking
- allow HTML in apps
37. Is it worth it?
What do you think? How difficult is it? Does it provide good benefits? Enough to be useful? I
need my approach to be actually adopted by developers.
40. This presentation is
licensed under a Creative
Commons BY-SA license.
Attribution for pictures through links.
Slides, materials, progress etc. can be found @
http://www.noroute.de/blog/diplomathesis
