Your SlideShare is downloading. ×
Web Application Security
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Web Application Security


Published on

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 -

Published in: Technology

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. 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!
  • 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
    • 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.
  • 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 are variables representing 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)
    • VALUES
    • ('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) for the current connection
      • Best: Prepared Statements ...
        • PHP: MySQLi, PDO
  • 22. 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
  • 23. SQL Injection Summary
    • Sanitize all input before using it in a query.
  • 24. 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.
  • 25. 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.
  • 26. 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!
  • 27. 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.
  • 28. 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=”” alt=”” width=&quot;1&quot; />
    • <img src=”” alt=”” width=&quot;1&quot; />
    • <img src=”” alt=”” width=&quot;1&quot; />
    • <img src=”” alt=”” width=&quot;1&quot; />
    • <img src=”” alt=”” width=&quot;1&quot; />
    • Your session is still active on site A, so you have just unknowingly deleted 5 accounts.
  • 29. 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.
  • 30. 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)
  • 31. 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.
  • 32. 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.
  • 33. 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.