Transcript Common_Application_Flaws

COMMON APPLICATION FLAWS
Back To Basics
Objective
: Provide an overview of common application flaws
: No ‘exploitation’ techniques
: Discussion based, to provide an understanding
: To provoke thinking
: Originally going to provide a Tokemon walkthrough
: Won’t work over conference call
Slide 2
OWASP Top Ten Summary
Cross Site Scripting
<script>alert()</script>
Injection Flaws
: SQL, LDAP, XML, etc
File Execution
: Scripting, RFI, shell execution
Direct Object Reference
: /access.asp?record=##
Cross Site Request Forgery
: Session riding, Accessing internal device
Slide 3
OWASP Top Ten Summary
Information Leakage and Error Handling
: Every bit of information helps an attacker
Broken Authentication and Session Management
: Login bypass, cookie manipulation
Insecure Cryptographic Storage
: Static keys, Non seeded encryption
Insecure Communications
: HTTP, Clear text internal web services
Failure to Restrict URL Access
: /adminportal/adminfunction?action=adduser&user=me
Slide 4
User Supplied Input Is The Cause
Comes from many places
: Passed on the URL, or as a parameter
: Passed in posted data, hidden fields
: Passed in HTTP headers, referer
: Cookie data, client certificates, files for import, etc..
THE USER CAN NOT BE TRUSTED... EVER
Validate ALL user input, server side
: Cint(), isDate(), len() <= x, isAlphaNumeric()
: Whitelist, NOT blacklist
: Decode input, in the correct order, and in the right case
Filter Output at use
: Different uses of data, require different filters
Slide 5
Faulty Filters Worse Than No Filters
/page.aspx?theID=1;exec xp_cmdshell ‘serverpwnage.exe’;
function cleanrequest(theID)
theID = lcase(theID)
if instr(theID,";") > 0 then
theID = left(theID,instr(theID,";")-1)
end if
if instr(theID,"exec ") > 0 then
theID = left(theID,instr(theID,"exec ")-1)
end if
Function To Filter
User Input
Looks For The Use
Of A Semi Colon
Looks For The Term
exec followed by a
space
This Filter Can Be Bypassed By Using A Tab Character As A Separator
/page.aspx?theID=1%09exec%09xp_cmdshell ‘serverpwnage.exe’;
Slide 6
Faulty Filters Worse Than No Filters
/page.php?htmlInput=<script>alert()</script>
Function To
function displayText(htmlInput)
Display User Input
htmlInput=str_ireplace("script", "",htmlInput)
Looks For The
echo htmlInput
Term script And
Remove It
Display The Filtered
Data
These Types Of Filters Are Just Rubbish!
/page.php?htmlInput=<sscriptcript>alert()</sscriptcript>
Slide 7
The Clean Server
Robots.txt / Sitemap.xml
: Often reveal more than they should
: Spiders don’t have to obey
Things that don’t belong
: Site archives
: .svn trees
: .inc, .cfg, .txt, bak, .backup
: Admin portals
: ‘hidden’ paths
: Virtual sites
Don’t Want It Indexed?
Don’t Link It!
Don’t Want It Found?
Don’t Put It There
http://www.owasp.org/admin/adminpage.php
http://www.owasp.org/admin/adminpage.bak
http://www.owasp.org/admin/adminpage.asp
http://www.owasp.org/admin/adminpage.inc
http://www.owasp.org/admin/adminpage.jsp
http://www.owasp.org/admin/adminpage.
http://www.owasp.org/admin/admin.php
http://www.owasp.org/admin/admin.bak
http://www.owasp.org/admin/admin.asp
http://www.owasp.org/admin/admin.log
http://www.owasp.org/admin/admin.inc
http://www.owasp.org/admin/admin.jsp
http://www.owasp.org/maintentance/
http://www.owasp.org/admin/admin.
http://www.owasp.org/adminportal/
http://www.owasp.org/_debuglogs/
http://www.owasp.org/_database/
http://www.owasp.org/adminsite/
http://www.owasp.org/_includes/
http://www.owasp.org/sysadmin/
http://www.owasp.org/backups/
http://www.owasp.org/console/
http://www.owasp.org/_debug/
http://www.owasp.org/_admin/
http://www.owasp.org/admin/
http://www.owasp.org/sites/
http://www.owasp.org/logs/
Slide 8
SQL Injection
Manipulation of the SQL query string
sqlString=
select * from users where name =‘+userinput’+’and password=‘+userinput
Becomes
select * from users where name =‘admin’;--and password=‘anything’
Or
select * from users where name =‘admin’ and password=‘anything’ or ‘1’=‘1’
Where
(name =‘admin’)
(and
(password=‘anything’)
or (‘1’=‘1’)
)
Syntax Grouping
Slide 9
SQL Injection
DO NOT BUILD SQL STATEMENTS DYNAMICALLY
Use parameterized queries
: asp, .net, java, php, python, flex?
Use stored procedures
: Type cast variables
: Don’t use dynamic SQL inside procedure
: Often seen in ‘search’ procedures
: Use the QuoteName function
Yes. Of course your
flash application
can be vulnerable
to injection attacks
SELECT @SQL = 'SELECT * from USERS WHERE NAME ='+ @Username
EXEC @SQL
Slide 10
SQL Truncation Attacks
Application vs SQL
: The form data is stored varies between the two
MySQL
: MySQL will truncate data during an insert
User=“admin<100spaces>x”
:
:
:
:
Column
Size
Name
100
..
..
PHP asks MYSQL “Any users by this name?”
MYSQL responds “No, I don’t know that person”
PHP says “Ok add a user by this name”
MYSQL says “Sure, his name is too long I’ll shorten it for you”
GEE THANKS
Slide 11
SQL Truncation Attacks
MSSQL
: Data is truncated when calling stored procedures
User=“[email protected]<100spaces>;[email protected]”
Input To A Forgotten Password
Page
: SQL returns record for admin
Create procedure [FindUser]
@username VARCHAR(100)
...
Parameter Has A Length 100
: Data mailed to both admin and attacker
Slide 12
Databases
Stored within the webroot
: /dbase/dbase.mdb
: Flat files etc..
Microsoft Used To
Recommend This.....
Running as ROOT or SYSTEM
: Or worse... A domain account
Encryption Of Data
: If the server or application is compromised, is the data?
Don’t Use A Static Key
Do Seed With User
Specific Data
: Unique record ID of the user account
: User supplied password
Slide 13
Cryptography
Encryption is difficult
: Do NOT roll your own XOR based encryption scheme
: BASE64 is not encryption
Weakness is in the implementation
: Verify your data is getting encrypted
: Use one way encryption for passwords
Storing the secrets
: Database credentials should never be stored clear text
: Encryption keys should not be stored in accessible configs
Slide 14
Application Email
Often vulnerable to spam attacks
: SMTP is a text based protocol
: CR/LF pairs and new command can be inserted
Normal communication with SMTP server
Mail From: <[email protected]>
Rcpt To: <[email protected]>
Data
Subject: This is a test email
.
quit
Slide 15
Application Email
Injection through recipient field
: [email protected]>%0a%0drset%0a%0dMail From:
<spam@foo.....
Modified communication with SMTP server
RESET
Injected
Mail From: <[email protected]>
Rcpt To: <[email protected]>
rset
Mail From: <[email protected]>
Rcpt To:
<[email protected]>
Data
Subject: This is a spam email
blah blah spam spam
.
quit
New Details
Injected
Slide 16
Cross Site Scripting
The sending of user supplied input to the browser
: More than alert()
Reflective
: Code passed as a parameter, usually on the URL
Persistent
: Code stored and then displayed to user
Consequences
: Cookie theft
: Site interaction
: Web application worms
JavaScript is a
powerful
programming
language
Slide 17
Cross Site Scripting
Example flaw
: echo “hello “.$_GET[‘username’].”welcome to the site”
Normal output
: <html>hello Brett welcome to the site</html>
Exploit output
: <html>hello <script>alert()</script> welcome ...</html>
Insert Any JavaScript Or
Script Inclusion
Widely Known, Well
Explained, Still Exists In
Most Applications
Slide 18
CSRF
Cross Site Request Forgery
: Attacking site causes browser to make a request to target
User logs into banking.co.nz
: banking.co.nz sets an authentication cookie
: User leaves but doesn’t log out
User browses to attacking site
: Attacking site creates a post to banking.co.nz
: Users browser sends cookie with post
: Browser is already authenticated
Slide 19
CSRF
Defence
: Each post must contain a random parameter value
Slide 20
Other Related Attacks
Site redirection
: User supplied input used as target page
http://site.com/login.php?redirect=<value>
Microsoft Still Do
This In Versions Of
OWA
: Can be used in phishing and scam attacks
Page inclusion
: User supplied input use as source for frame, iframe, image
<frameset>
<frame src="topbar.html">
<frameset>
<frame src="<%=request("page")%>">
</frameset>
</frameset>
External Content
Displayed In Browser
Slide 21
Cookie Security
Don’t store credentials in the cookie
: Set-cookie: user=admin
This Sort Of Thing Still
Happens!
Set the cookie path
: Specifies which part of the application the cookie is sent to
Secured Blog Posting Section
http://Application/secure/login
Requires Auth
Cookie Set
http://Application
Insecure General Section
http://Application/general/read
If The Cookie Path Is Not Set
A Vulnerability In The General Section Can Read The Secure Section Cookie
Slide 22
Cookie Security
Set the SECURE flag
: Prevents the cookie been sent in HTTP requests
: Cookie sent even if target site not listening on HTTP
Attacker Needs
Access To Sniff
The Traffic
Set the HTTPOnly Flag
: Prevents access to the cookie through JavaScript
: Defence against cross site scripting
Slide 23
File Uploading
File uploading is dangerous
: Provides the ability for the user to create data on server
: Usual attacks involve uploading a script file for access
Check the file extension
: Check the portion after the last .
: Compare against WHITELIST
Beware The NULL
(%00) byte
Check the file data
: Valid graphic, csv, numeric data
Store as blob in database
: Do NOT store as raw file under webroot
Slide 24
File Include Attacks
Local file include
: Occurs when user can affect or supply a file path
: Leads to disclosure of source and other sensitive items
http://site.com/help.jsp?helppage=/help/index.html
Remote file include
: Occurs in PHP (usually), when an HTTP reference is provided
: Is disabled in modern versions of PHP
.Net LoadControl
: Can be used to load arbitrary controls that exist on server
If you must accept paths from a user
: Reject anything that is suspect. Ie; ../../ ..\..\ %xx
Slide 25
Configuration
What is wrong with these?
<Limit GET>
order deny,allow
deny from all
allow from 203.10.1.104
allow from 192.168.1.1
</Limit>
.htaccess
<location path=“admin.aspx“>
<system.web>
<authorization>
<deny users="?"/>
</authorization>
</system.web>
</location>
Web.config
Slide 26
www.insomniasec.com