Top Banner

of 33

Web Application Security

Nov 02, 2014



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

  • 1. Web Application Security A brief introduction to developing more secureapplications for a safer internet. Do not hesitate toask any questions throughout the presentation!

2. 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

3. Responsibility

  • As a developer, it's our responsibility to develop secure applications.
  • This responsibility is both moral and in many cases, legal.

4. The Risks

  • If you develop a sub-par application, and deploy it to a production environment, then
  • YOUare 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.

5. 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

6. 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.

7. 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

8. 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...

9. 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 10.

  • 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 11. 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)

12. 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');

13. SQL Injection

  • SQL injection occurs when we put untrusted input into a database query.
  • Example:
    • $username and $password arevariablesrepresenting fields posted through a form.
    • INSERT INTO user
    • (username, password, admin)
    • VALUES
    • ('$username', '$password', false);

14. 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.

15. SQL Injection

  • The good kind:
  • Something broke.
  • That's all you need to know...

16. 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)
  • ('Mr. O'Neil', 'f4k3p4ssw0rd', false);
  • Not only does this confuse/anger the visitor, but it reveals sensitive information about your application.

17. 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.

18. 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

19. SQL Injection Example

  • Often you'll see URLs like this:
  • 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.

20. 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. ( '' )

21. 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) forthe current connection
    • Best: Prepared Statements ...
      • PHP: MySQLi, PDO