Presentation on theme: "Adrian Crenshaw. I run Irongeek.com I have an interest in InfoSec education I don’t know everything - I’m."— Presentation transcript:
I run Irongeek.com I have an interest in InfoSec education I don’t know everything - I’m just a geek with time on my hands I’m also not a professional web developer, creating crappy code was easy or me. So why listen to me? Sometimes it takes a noob to teach a noob.
OWASP Top 10 (As a side note, I’ve copied quite of few of their descriptions and fixes into this presentation) Mutillidae deliberately-vulnerable-php-owasp-top-10 deliberately-vulnerable-php-owasp-top-10 Ok, but what are those?
The 2007 list includes: A1 - Cross Site Scripting (XSS) A2 - Injection Flaws A3 - Malicious File Execution A4 - Insecure Direct Object Reference A5 - Cross Site Request Forgery (CSRF) A6 - Information Leakage and Improper Error Handling A7 - Broken Authentication and Session Management A8 - Insecure Cryptographic Storage A9 - Insecure Communications A10 - Failure to Restrict URL Access The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are.
A teaching tool for illustrating the OWASP 10 Written in PHP/MySQL Meant to be simpler than WebGoat Simple to exploit, just to get the concept across Easy to reset Includes a “Tips” function to help the student
1. Download Mutillidae deliberately-vulnerable-php-owasp-top-10 deliberately-vulnerable-php-owasp-top Grab XAMPP Lite and install it 3. Put the Mutillidae files in \htdocs 4. May want to edit xampplite\apache\conf\httpd.conf and set “Listen :80 “
XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc.
Input validation. Strong output encoding. htmlspecialchars() Specify the output encoding. Do not use "blacklist" validation to detect XSS in input or to encode output. Watch out for canonicalization errors.
Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data.
The Code: “SELECT * FROM accounts WHERE username='". $username."' AND password='".stripslashes($password).”’” or echo shell_exec("nslookup ". $targethost);'“ Expected to fill in the string to: SELECT * FROM accounts WHERE username=‘adrian' AND password=‘somepassword’ or Nslookup irongeek.com But what if the person injected: SELECT * FROM accounts WHERE username=‘adrian' AND password=‘somepassword’ or 1=1 -- ’ or Nslookup irongeek.com && del *.*
SQL Injection Cheat Sheet SQL Injection Attacks by Example Command line Kung Fu
Input validation. Use strongly typed parameterized query APIs (bound parameters). Enforce least privilege. Avoid detailed error messages. Show care when using stored procedures. Do not use dynamic query interfaces. Do not use simple escaping functions. Watch out for canonicalization errors.
Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users.
Grabbing a local file: viewer.php&php_file_name=config.inc viewer.php&php_file_name=config.inc Tamper Data, POST data and an inadvertent proxy
Strongly validate user input using "accept known good" as a strategy Add firewall rules to prevent web servers making new connections to external web sites and internal systems. Consider implementing a chroot jail or other sand box mechanisms. # PHP: Disable allow_url_fopen and allow_url_include in php.ini and consider.building PHP locally to not include this functionality. # PHP: Disable register_globals and use E_STRICT to find uninitialized variables. # PHP: Ensure that all file and streams functions (stream_*) are carefully vetted.
A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.
You already saw it with the malicious file include demo.
Avoid exposing your private object references to users whenever possible, such as primary keys or filenames. Validate any private object references extensively with an "accept known good" approach. Verify authorization to all referenced objects.
A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.
Target Web App Client Website the attacker controls 1 1.Session established with web app via a cookie. (already logged in) 2.At some later point, content that the attacker controls is requested. 3.Attacker serves up content that asks client’s browser to make a request. 4.Client makes request, and since it already has a session cookie the request is honored
Let visit a page with this lovely link: Don’t want to use a bad image? Try an Iframe: Can’t use the GET method? Try something like: document.csrfform.submit()
CSRF Flaws Found On Major Websites, Including a Bank CSRF Home Router Fun adsl-gateway-with-speedbooster-wag54gs/ adsl-gateway-with-speedbooster-wag54gs/ CSRF in Gmail
For sensitive data or value transactions, re-authenticate or use transaction signing to ensure that the request is genuine. Do not use GET requests (URLs) for sensitive data or to perform value transactions. (see next point) POST alone is insufficient protection. Consider adding Captchas and extra sessions values as hidden form elements.
Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks.
Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities.
Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.
Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.
Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.
Deliberately Insecure Web Applications For Learning Web App Security berately-insecure-web-applications-for-learning- web-app-security berately-insecure-web-applications-for-learning- web-app-security
SamuraiWTF OWASP Live CD BackTrack
Free ISSA classes ISSA Meeting Louisville Infosec Phreaknic/Notacon/Outerz0ne