• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Web Application Security

Web Application Security



My talk on web application security, focusing on developer responsibility, risks, and highlights SQL injection, XSS and CSRF. Presented to OKDG -...

My talk on web application security, focusing on developer responsibility, risks, and highlights SQL injection, XSS and CSRF. Presented to OKDG -




Total Views
Views on SlideShare
Embed Views



1 Embed 1

https://twitter.com 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Web Application Security Web Application Security Presentation Transcript

    • Web Application Security A brief introduction to developing more secure applications for a safer internet. Do not hesitate to ask any questions throughout the presentation!
    • Adrian Schneider
      • CTO / Co-Founder of Startup:
        • Upscale International
      • 6 years of development on the web
      • Zend Framework / OOP Enthusiast
      • Worked with hundreds of online communities
          • High traffic / large data sets
          • High profile / angry members / high attack rates
    • Responsibility
      • As a developer, it's our responsibility to develop secure applications.
      • This responsibility is both moral and in many cases, legal.
    • The Risks
      • If you develop a sub-par application, and deploy it to a production environment, then
      • YOU are at risk.
      • Your job, your reputation, your business...
      • It doesn't matter if you are a freelancer, a contractor, an employee or a business owner.
    • The Risks
      • The Client or Customer
          • Their credibility
          • Their sensitive information
          • Their website / business
          • Their revenue
        • The Visitor
          • Their trust in your client / website
          • Their sensitive information
          • Their computers
    • The Risks
      • Websites take a long time to earn trust
      • Trust is psychological, but can also extend to the visitor's browser security settings
      • Legal implications / Privacy Policy
      • Trust is very difficult to earn back
          • The average person trusts a stranger more than somebody has broken their trust.
    • The Risks
      • Read/write/delete content
          • Pages
          • Visitor Accounts / Admin Accounts
          • Other websites or information on your server
          • Other sensitive information
      • Add viruses to your website
          • Visitors can no longer trust the site
      • Use your server for other attacks, or spam
          • You can get blacklisted from sending mail
          • You are now part of the problem
    • What is Hacking
      • Hacking is exploiting flaws in a system to do things that you shouldn't be able to do
      • Let's look at how an application typically works...
    • An Application
      • Applications read input, and respond with output.
      -GET (URL) -POST (Form data) -Cookies Rendered Web Page (or XML, JSON, etc.) Sessions Database File System etc. EXTERNAL VARIABLES OUTPUT INPUT APPLICATION 0
      • Never trust ANY user input
      • This includes
          • URL / Query String (“/posts/?p=5”)
          • POST Data (form submissions, uploads, etc.)
          • Cookies
      • Always note data type. If you expect an number, then force it to be one.
          • What happens when the user enters other types? (arrays, for example)
      User Input is Malicious
    • Types of Attacks
      • SQL Injection
      • Cross Site Scripting (“XSS”) &
      • Cross Site Request Forgery (“CSRF”)
      • Others...
          • DNS Poisoning
          • DoS / DDoS attacks
          • Session Fixation
          • Brute Force / Rainbow Tables
          • Spoofing (IP, Referrer)
    • SQL Injection
      • What is SQL?
          • Database access language
          • (programmatic access to spreadsheet-like data)
          • This is how applications typically read/write data
      • Reading:
        • SELECT title, message FROM comment;
      • Writing:
        • INSERT INTO comment
        • VALUES ('x', 'y', 'z');
    • SQL Injection
      • SQL injection occurs when we put untrusted input into a database query.
      • Example:
        • $username and $password are variables representing fields posted through a form.
        • INSERT INTO user
        • (username, password, admin)
        • VALUES
        • ('$username', '$password', false);
    • SQL Injection
      • For the average visitor, this is okay.
      • What happens if the user's name contains a single quote, which is used to separate the query instruction from a literal value?
      • They'll get some sort of error page.
    • SQL Injection
      • The good kind:
      • Something broke.
      • That's all you need to know...
    • SQL Injection
      • The bad kind:
      • You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''' at line 1
      • INSERT INTO user
      • (username, password, admin)
      • VALUES
      • ('Mr. O'Neil', 'f4k3p4ssw0rd', false);
      • Not only does this confuse/anger the visitor, but it reveals sensitive information about your application.
    • Error Handing
      • Never show errors in production
      • Log errors so they can be fixed
          • Do check for them
          • Or have them emailed instead
      • This way you will see potential bugs/security holes, and you can fix them promptly.
      • You may even catch hackers in the act.
    • SQL Injection
      • Examples of exploits:
          • Writing data to fields the user was not supposed to.
          • Reading restricted data, and displaying it on the page.
            • MySQL's built in tables (ex: user accounts)
            • Other data on the site (visitor accounts, private content, etc.)
          • Executing multiple queries
            • Potentially deleting entire tables, modifying privileges, etc.
            • Inserting data into other areas of the site, or other sites on the same database server
      • The attacker is often limited by:
          • The actual query they are modifying
          • Database configuration & permissions
    • SQL Injection Example
      • Often you'll see URLs like this:
      • http://site.com/page.php?id=12
      • Simply inserting a ' after the 12 should reveal if the page is easily exploitable.
      • If it is, you can potentially pull any information from the database and display it on the page.
    • Preventing SQL Injection
      • Do not use user input directly in queries.
      • To prevent quotes from breaking the query, you must “escape” them.
      • To escape a quote, you put a backslash in front of it.
          • In MySQL (depends on your database)
          • Some systems use a second quote to escape it. ( '' )
    • Preventing SQL Injection
      • Bad: do not simply escape quotes!
          • PHP: addslashes() - converts ' to '
          • There are ways around this!
      • Good: use your database's built-in escape functions
          • PHP: mysql_real_escape_string
          • Properly handles your database's character set (multi-byte characters) for the current connection
        • Best: Prepared Statements ...
          • PHP: MySQLi, PDO
    • Prepared Statements
      • Instead of including user input in queries, a prepared statement sends it separately.
      • SELECT * FROM user WHERE id = :user_id
      • :user_id is a placeholder, and the values no longer need to be escaped to avoid injection.
      • Code quality also increases
          • No more nasty concatenation
          • No more hoping you escaped every query properly
    • SQL Injection Summary
      • Sanitize all input before using it in a query.
    • Cross Site Scripting (XSS)
      • Occurs when users modify HTML on your site.
          • This can be from posting HTML into something that gets saved and shown to other visitors
          • This can be from linking to your site from their own site if you directly show input on the screen.
    • XSS Risks
      • Attackers can hi-jack your user sessions.
          • This can include admins
          • At this point, all content on your app is at risk again.
      • Attackers can inject malicious HTML
          • Client-Side security typically sucks. (Think IE6)
              • (Browser exploits, Font exploits, PDF exploits, etc.)
          • These are things that can damage the visitor's system.
              • Viruses, other cookies, saved passwords, remote file execution, etc.
          • At this point, the site's credibility is completely shot.
    • Preventing XSS
      • Do NOT allow users to post HTML
          • Filter out any HTML tags if possible
          • Partial filtering is hacky, and unreliable (allow only <strong>, <em>, etc.)
          • Inline CSS and JavaScript is also vulnerable!
      • Always escape any user content before printing it on the page.
          • <script>alert('XSS')</script> -> &lt; script &gt; ....
      • This includes non-obvious input, such as URL parameters or even the request URL!
    • Cross Site Request Forgery (CSRF)
      • This one is not so easy.
      • CSRF occurs from remote sites, when the remote site can perform actions on your site on behalf of the user.
      • These attacks are extremely dangerous, and are very often overlooked.
    • Basic CSRF Example
      • Let's assumed you are logged in to your site (“A”), or your session is still active.
      • You visit site B, which contains this:
      • <img src=”http://yoursite.com/admin/user.php?do=delete&id=1” alt=”” width=&quot;1&quot; />
      • <img src=”http://yoursite.com/admin/user.php?do=delete&id=2” alt=”” width=&quot;1&quot; />
      • <img src=”http://yoursite.com/admin/user.php?do=delete&id=3” alt=”” width=&quot;1&quot; />
      • <img src=”http://yoursite.com/admin/user.php?do=delete&id=4” alt=”” width=&quot;1&quot; />
      • <img src=”http://yoursite.com/admin/user.php?do=delete&id=5” alt=”” width=&quot;1&quot; />
      • Your session is still active on site A, so you have just unknowingly deleted 5 accounts.
    • More on CSRF
      • CSRF doesn't just need to be a GET request. You can also post form data back to the vulnerable site, even avoiding requiring any action from the user.
    • CSRF Solution
      • You only want to accept requests that originated from the same site.
      • Check referring page
      • Generate a security token at login, and pass it with each form. Deny all submissions that do not have the correct token.
      • Token should be a randomly generated string (such as a hash)
    • Notable Attack Victims
      • GMail
      • YouTube
      • All Google Sites (again)
      • eBay
      • Twitter
      • MySpace
      • Digg
      • BC Online Gambling Site (last month)
      • Most of these were XSS / CSRF attacks.
      • SQL Injection tends to happen more on lower profile sites.
    • Closing Best Practices
      • Don't store plain-text passwords. Ever.
          • Encrypt passwords with proper algorithms OR
          • Hash passwords with salt
      • Always give minimum access to server accounts
          • File permissions
          • Don't run things as root
          • Database privileges should be restricted (drop tables?)
      • Use different accounts/passwords
          • If one gets compromised, the rest will still have a chance.
          • Secure passwords too please. Symbols are fun.
    • Summary
      • Be responsible for your application
      • Properly sanitize all input before using it
      • Validate user sessions
      • Apps will never be 100% secure, because:
          • Client machines can be compromised
          • People use weak passwords, or give them out openly
          • Network communications can be intercepted
          • Hosting environment can be compromised
          • Technology is always advancing
        • Do everything you can. Stay up to date.