Your Web Application Is Most Likely Insecure
•
3 j'aime•2,465 vues
This presentation outline the common security risks in web application today. What they are, how to find if your application is at risk and the remedies.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (19)
Similaire à Your Web Application Is Most Likely Insecure
Similaire à Your Web Application Is Most Likely Insecure (20)
Plus de Achievers Tech
Dernier
Dernier (20)
Your Web Application Is Most Likely Insecure
- 1. Web Application Security Matt York
- 2. • Slides and code will be posted on the meetup group: http://meetup.com/achieverstech • Video will be posted on: achievers.com/tech • Tell your friends! 300!
- 3. About Me • Joined Achievers in October 2009 • Dev Manager @ Achievers • Professional Experience: – Web and desktop apps with Java, J2EE, Spring, Hibernate – PHP with CodeIgniter – Blackberry mobile development (ouch!)
- 5. Scalability PHP Frameworks Optimizing MySQL Queries Security
- 6. Average $6.5M in damages per incident Twitter, Facebook, and MySpace have all been affected by Cross Site Scripting 70% of all vulnerabilities are at the web application layer 73% of all organizations have been hacked in the past 2 years
- 7. Goals • To NOT make the audience fall asleep • To teach you ABOUT web application vulnerabilities • To show you how to FIND web application vulnerabilities • To DEMO web application vulnerabilities • To show you how to FIX web application vulnerabilities
- 8. Agenda • Intro to supersecurebank.com and smrtattacker.com • Intro to Burp Suite • Start testing how secure this bank really is • Help the bank out and fix some of their vulnerabilities
- 9. supersecurebank.com • The best bank around • Secure • Full of great features • Amazing UX/UI!
- 10. smrtattacker.com • A hacker’s site • Contains tools for executing exploits on other websites • Amazing UX/UI!
- 11. Burp Suite
- 12. Burp Suite “I will never develop an application again without Burp Suite.” - Matt York “I would spend my own allowance on this tool!” - Dr. Aris Zakinthinos
- 13. Burp Suite • An amazing security testing tool • A great tool for the $$$ (about $300/yr) • Very good at automatically finding basic vulnerabilities • Good features for doing your own manual testing
- 14. Burp Suite – How Does It Work?
- 15. Burp Suite Let’s take a look …
- 16. TIP: Don’t Give Away Too Much • Hide any details you can about the implementation of your system • Remove unnecessary headers • Verbose error messages
- 17. TIP: HTTPS (OWASP A9) • HTTPS for protecting the transmission of sensitive data • HTTPS is not a silver bullet • Session cookies • Not all HTTPS encryption algorithms are equal • SSL, TLS, and different versions – What do your customers require? What is “good enough”?
- 18. TIP: Passwords (OWASP A7) • Brute forcing passwords and usernames • Password policies: • Min. characters • Numbers, letters, and symbols • Time to change • Do you have a good strategy in case your system does get compromised? • Hashing: MD5, SHA1, Bcrypt
- 19. Salt and Pepper • Not the fabulous musical group • Salt (per user) – HASH(password + saltU1) – HASH(password + saltU2) • Pepper (per system) – HASH(password + saltU1 + pepper) • Eg: password=“apples”, salt=“1394933”, pepper=“ajasdfasf”
- 20. TIP: Iframes • Allowing your site to be hosted in an iframe has potential for users to do things they didn’t intend to do • X-Frame-Options header • Frame-busting
- 21. TIP: Account Harvesting • Again, don’t give away too much • Usernames are one half of the login process • CAPTCHAS • "Completely Automated Public Turing test to tell Computers and Humans Apart"
- 22. TIP: SQL Injections (OWASP A1) • Running un-intended SQL queries on your database by passing SQL through request parameters • Limit what your application DB user can do • Know your database settings: MYSQL_OPTION_MULTI_STATEMENTS_OFF
- 23. TIP: Cross Site Scripting (OWASP A2) • XSS enables attackers to inject client side script into web pages viewed by other users • Typical example is an alert • One of the most common attacks on websites
- 24. TIP: Session Cookies (OWASP A3) • Http-only flag • Secure flag (for HTTPS sites)
- 25. Preventing Cross Site Scripting • Output Encoding • XSS Filtering
- 26. TIP: Cross Site Request Forgery (OWASP A5) • XSRF exploits occur when a website allows an authenticated user to perform a sensitive action but does not verify that the user is invoking that action
- 27. Preventing Cross Site Request Forgery • REST • XSRF Cookie and Token
- 28. Insecure Direct Object Reference (OWASP A4) • Kind of a complicated name, right? • Think! Slow down!
- 29. Final Random Tips • type=“file” • Dot dot slash dot dot slash • Don’t email out passwords! • Set Content-Type headers • Validate your redirects
- 30. Summary • Start with good architecture and design • Tradeoffs • How do you stay secure? • Its not that hard! • Security is important
- 31. Good Security Resources • OWASP – The Open Web Application Security Project https://www.owasp.org/index.php/Main_Pa ge • Burp Suite • http://ha.ckers.org/ (no new material) • http://code.google.com/p/skipfish/ • http://code.google.com/p/ratproxy/
- 33. Announcements • Achievers is hiring! (tech@achievers.com) • Hackernest meetup – Nov 26th @ Achievers • Movember – Tech Talks / Beer / Food is Free • Drinks!
Notes de l'éditeur
- Thanks ZakWelcome to Achievers Tech TalkGreat to see so many people here – familiar facesReally excited to present to you today about web application security
- A few housekeeping items before we get goingWe want to give back to the community what we have learnedWe want to have conversations about topics so we encourage lots of questions and comments from your own experience
- As well, Aris (who you probably recognize from previous tech talks) and Kaelen are highly knowledgeable about security so they may jump in if anyone asks any difficult questions. Hopefully we will be seeing Kaelen doing a tech talk on something really smart one of these days.
- How many people have been to a previous tech talk? A lot of our previous tech talks have told a journey about Achievers’ evolution and rapid growth
- How many people have been to a previous tech talk? A lot of our previous tech talks have told a journey about Achievers evolution and rapid growth. Security is one of those things that as your company grows, and so does the size of your customers, you will get asked about more and more. When you are answering RFPs from customers and getting requests for pen tests is nice to have answers and know that you have some good security practices in place.
- I stole this slide from Zak’s presentation on Web Application Frameworks.Like software, all good presentations are reusable.We need to protect ourselves Incidents of web application attacks are on the rise and can cause your business financial damages and damages to your reputation.
- Security can be a pretty boring topic: http://www.youtube.com/watch?v=rj1ObuM6ims. I was sitting down watching some youtube security videos the other day and actually fell asleep. So we are going to try and keep things interactive and fun I think we offer a unique perspective because we are delivering the presentation from company standpoint rather than an hacker or someone who works as a full time security tester. Security has many different realms: physical security, infrastructure security, etc. etc. we are going to focus on web app vulnerabilities (as we saw above…these make up 70%) We aren’t going to dive into all the latest, bleeding edge vulnerabilities such as HTML5 vulnerabilities (you will need to go to DefCon for that…which I really would like to) but we are going to give you a good understanding of some of the most common vulnerabilities and what to do about them. The vulnerabilities that we are going to look at are mostly found on the OWASP Top 10 list. This list is a great resource that includes the most common web application exploits and you will see them referenced throughout the presentation. I’ve included a link to the OWASP website at the end.
- I have created two web applications for demonstrating some vulnerabilities Burp is a great security testing tool that we love at Achievers.Next, we are going to actually look at “super secure bank” and take a look into what kind of problems burp flags and what we can see using other simple observations about the code and architecture.
- All of the wealthiest executives do their banking here. We doing most of the demonstration using one of the banks customer named Brennan Davidson. Please excuse the UX/UI of the bank. It’s not the banks strong point – security is (or will be!)
- - Again, please excuse the UX/UI. It’s not the hackers strong point – stealing money and information is.
- - Lets start with some quotes.
- Great tool Not only for security. Really good at seeing what is going on in your application. GET vs POST
- A lot of very expensive tools out there that don’t do much more. There are free tools too, but they aren’t quite there in terms of functionality and usability ??? What kind of basic vulnerabilities do people know about (Swag throw) Most of the hard to find things involve manual testing and understanding the application details. Burp is great at helping you accomplish too, but if you are using this is where you should let any help focus their time).
- Burp Suite is a proxy that sits between your browser and your application It monitors requests that it sees going to your application and then sends its own modified, malicious, versions. This approach is great because it allows you to capture all requests on the way out of the browser and modify them before they get to the server. This is very good at illustrating that client side validation is never good enough and should basically be ignored in your testing (maybe this is something that should have a global flag to turn off in your application?) Its also a extremely important as applications get richer, more interactive, UIs that depend less on backend logic (don’t forget the validation logic!)
- Come along way in the UI. As you can see its built using Java Swing, so it will run on Windows, Mac, Linux. Some of you are probably cursing Swing right now but they have actually done a pretty good job.Proxy -> Options (listening on 8080) - As I said earlier, Burp is a proxy, we need to tell the webbrowser we will be testing with to connect with the proxy rather than directly with the server (show setup in FF. Tools->options->advanced->network->connection:settings button). Target -> Scope Proxy -> Intercept A very powerful tab: Go to supersecurebank.localhost.com (we can see that the page doesn’t load a burp intercept has changed colour. The details of the request are listed) here we can look at the request, simply forward on the request, or do some more advanced things with the request that we will talk about later. Its also a very good way of testing that burp is actually intercepting requests. forward request on. Another request for a CSS file. And turn intercept off Scanner -> Scan queue Scanner is the main tool in burp that replays requests to uncover security vulnerabilities Live Scanning – “Scan Everything” can be dangerous. Don’t want to scan other sites.(shows a list of all completed and active urls that burp is scanning. You can see that numerous request have been made for each url and some issues have been recorded) Scanner -> Results (Here you get more detailed results about the issues that burp found) When you click into a result, you get a quite thorough description and idea of how to fix the issue- Go into response (talk about headers that give away info about server software)
- Hackers can speed up their attack by knowing details about your system and target specific known vulnerabilities of the technologies you are using. Remove any unnecessary headers. Another issue that hackers can use to gain information about your system is verbose error messages. Error messages should never included details (like stack traces) about the “technical issue”>>> Back to burp turn scanner on for homepage
- Any sensitive information should not be transmitting in the clear over HTTP. Many security vulnerabilities exist even with HTTPS (most of the ones we are going to be talking about) If you are using a session cookie to track authenticated users and have parts of your site that are not over HTTPS, then you have the potential for session hijacking. This means that someone intercepts your request, grabs the session cookie, and reuses it to accesss the site. Some preventative measures for this if you don’t have HTTPS on the entire site are: include the IP address and user-agent in the session cookie and then encrypt the session data rotate session ids (so that the attacker only has access to your side for the time before the id changes) turn off weaker algorithms (DES, and other ciphers with keys less than 128 bits)
- This password page doesn’t seem ever stop you from entering invalid passwords. Would be pretty easy to use burp to continually try username and password combinations until we were logged in. Database passwords should not be stored in the database in clear text. Ideally that are hashed using a one way functionNot all hashing algorithmsare equal ??? Who in the audience knows what a password salt is (swag throw) This is important because if an attacker gains access to your user data it’s much easier to TODOPolicies are also very important (if you allow users to have 1 character passwords, someone probably will!)Security isn’t just about finding holes and patching them it’s also about strategies and how you recovery from exploits (some people say no website is secure and all have the potential to be compromised)- Encryption issues can also include how you store sensitive data such as credit card numbers and social security numbers.
- ??? Who in the audience knows what a password salt is (swag throw) This is important because if an attacker gains access to your user if we are simply using a hash algorithm all of the users hashed passwords will be the same. Pepper is a system level value, stored outside of the DB, that is thrown in before hashing. If someone grabs your database they don’t have the pepper and will have a more difficult time cracking your passwords.
- This is called Clickjacking - X-Frame-Options works in most browsers but not all Frame busting javascript (which basically breaks an iframe and puts the content in the main browser window) is a good idea but can be circumvented. Combination of both is best This is one of those vulnerabilities that is a trade off between security and usability (do your customers really need to host your site in an Iframe? What types of things could an attacker trick a user into doing) Lets dive into the site and take a look at some of the features (actually I forgot my password)
- So what we just saw was that the page gives a different message if the username is not found. Using brute force techniques we can figure out a valid user name. We Really should return a common generic message. ??? Who can tell me what a CAPTCHA is (Swag Throw)Captchas are those annoying little images on some sites that you have to enter the text into the box below them This is the second time we have mentioned brute force attacks. CAPTCHAS can limit exposure to brute force attacks, but are one of those usability tradeoffs (Takes me 10 tries to solve some captchas!)We’ve explored the two unauthenticated pages. At this point I want to highlight how you should pay even more attention to the un-authenticated pages because even an un-authenticated user can execute an exploit against themSo lets dive into some of the features on the site!
- SQLcan range from logging in with bad credentials (demo) or completely dropping a tableDo they need to be able to DROP a table. Probably not! Was trying to do a DROP an noticed that I couldn’t execute a second query. This setting can actually be controlled in MySQL server options
- One of the most common security vulnerabilities Impacts can range from an annoying pop up to stealing customer sessions and data. demo: clear burp data in feedback table….script alert then img attack
- In our example, the session cookie was appended as a parameter to the image hosted on the attackers domain. The cookie value was accessed using the javascriptdocument.cookies functionality. Access to the cookie can be prevented using the http-only flag Also, if your site is entirely over SSL you can put a secure flag on your cookies. This only sends the cookie for Https URLs.
- clear dbThe purpose of output encoding is to convert untrusted input into a safe form on the webpage An example of this is converting angled brackets to entities so that that the script tags arent executedOuput encoding exploits are also prevelant in Javascript (especially with the rise of AJAXy applications) and CSS show output encoding XSS Filtering, or more generally data filtering, is allowing only the intended data to be taking from a request and used in your application (displayed on a page or stored in the DB). show filtering XSS- header – benefits / problems / browsers
- XSRFattacks occur because websites typically don't verify that a request came from an authorized user. Instead they verify only that the request came from the browser of an authorized user The exploit assumes the user that the exploit is targeted against is logged into the site the exploit is targeted against. So, back to our website: Brennan Davidson LOOOVES the blackberry playbook and gets an intriguing email linking to a website. The next day he checks his account and notices a transaction that he didn’t authorize.
- ??? Who in the audience knows what REST is? (swag throw)REST stands for Representational state transfer One of the main ideas in REST is that specific HTTP methods are used for specific types of actions. GET gets you data, while POST adds or modifies data. In the example, the account form uses a GET method to do the transfer. Switching this over to POST would render the Iframe method useless, but there are still ways to get around this. What we need is a way ensuring that the POST request originated from the authenticated user. <<CLICK>> One way to do this is to generate a token on the GET of the FORM page and store it in a cookie (or on the server). Then also pass the same value along as form data in the post. If the two values don’t match, don’t process the form submission. Lets see how we can do this in CI. Update FORM Update config Update account get_post Show HTML form source with Firebug Lets checkout the address functionality of the site
- What this really means is getting access to stuff that isn’t yours or you don’t have rights to! This is one of the things that I mentioned before that is harder to test for and requires manual testing. Burp can be pretty helpful for this. For example using the repeater to fire off modified requests. Most of these errors are pretty silly when you find them and can easily be avoided by slowing down and thinking about what you are doing. Another point is that checks like this need to happen everywhere in the feature, GET, POST, Multi page flows Can anyone in the audience of other examples of things like this? (profile pages, admin sections of sites)
- Watch out for file inputs. Always check what types are being uploaded on the server (don’t just use a content type header). Should also go a level deeper and check the file contents. Rename files Watch out for bad file paths. Always use canonical paths. Don’t just echo things out – some older browsers have issues with how they guess content-types
- Bolting secure on to existing projects is a lot harder than starting with some basic security best practice and proceduresLike a lot of aspects of computer science, security is about tradeoffs. We need to find the right balance between usability and security. Getting a site to a certain level of security is hard. Its even harder to maintain that level of security when you are constantly updating your system. Some ideas on how to stay secure Get security training and tools in the hands of developers and QA Make security part of code reviews. Setup automated security scans with Burp as part of your continuous integration process Setup source code repository hooks. For example, send an email out for review when someone creates a new un-authenticated controller or touches a critical file. ??? Ask audience for some more ideas (Swag Toss)- With the right set of tools and some process, its not rocket science. I hope that people understand the importance of web application security. Attackers are getting more sophisticated and incidences of security breeches are on the rise. Breeches are embarrassing and costly to your organization. Thanks very much…I hope you learned a lot.
- I only included the OWASP URL because I thought it was interesting that they chose to include the .php extension !!!ratproxy: semi-automated proxy (like burp). No UI, Intercepter, Repeater etc. Performs passive testsskipfish: scanner spiders and builds a site map. Performs active tests against URLs it finds.