Your SlideShare is downloading. ×
Web Security: What's wrong, and how the bad guys can break your website
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Web Security: What's wrong, and how the bad guys can break your website


Published on

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. Seattle PHPUsers Group:SecurityJune 13th, 2013
  • 2. Hello!Andrew
  • 3. First, a few questions for you1. Have you dealt with a successful attack onyour website?2. Do you have a security response procedureand development strategies to handlesecurity problems?3. Do you have an intrusion detection systemor web application firewall deployed?4. Are you using shared, managed, ordedicated hosting?
  • 4. A brief background● PHP 5.2+ (2007)● Zend Framework 1.x and some 2.x● Sysadmin of Apache/Nginx/IIS productionsystems at SMBs● Main focus is security since about 2010.● Intern at Leviathan Security Group (startingJune 17th).
  • 5. Why web security?Websites a prime target for evil doers,because..● Your website is available to anyone● Your information is stored in one place● Successful compromise of a single websitecan be of value when comprising anotherindividual.● There are plenty of problems for developersto deal with, and its difficult to implementmeasures against all of them.
  • 6. Scenario: Abusing program input1. You expected an integer, but I gave you astring.2. But theres no way to be sure of it (weaktyping) without checking explicitly (filter_var)3. And you forgot to check it4. So now anyone can do something theyshouldnt be able to.
  • 7. Program Inputs the issue, sureWe know program input can break ourprogram, but what kind of input?● Null or empty strings● Out of range numeric types, overflow● Datatype issues (string vs integer)● Injection (SQL/XSS)● Valid, but out of place (i.e.: direct objectreference)
  • 8. But its not just program inputNot all security issues result in a compromise(or even any indication of a page beingaccessed) on your server.Example: What happens if someone uses theback button after they log out of your website?Example: what can I see by looking at thenetwork traffic?
  • 9. So whats the problem anyway?(Yes, another OWASP top 10):● Injection● Broken authentication● Cross-site scripting● Insecure direct object reference● Security misconfiguration● Sensitive data exposure● Missing function level access control● Cross site request forgery● Using known vulnerable components● Unvalidated redirects and forwards
  • 10. SQL Injection with RobotsFetch item number ____ from section ____ of rack number____, and place it on the conveyor belt.Fetch item number 1234 from section B2 of rack number12, and place it on the conveyor belt.Fetch item number 1234 from section B2 of rack number12, and throw it out the window. Then go back to yourdesk and ignore the rest of this form. and place it on theconveyor belt.
  • 11. Cross Site Scripting (XSS)<input name="search" type="search" value="test" onmouseover="alert(xss);"/>If *one* page of your site has an XSSvulnerability, chances are your entire site is atrisk.Escaping is great, if you can remember to do it*everywhere* and you dont require rich text.
  • 12. Cross site request forgeryHello, Hello! Im and Id liketo send this information under the currentlylogged in user? Oh sure. Ill handle that.Solution: Use a CSRF token on every formBetter yet, find a framework or library (likeZendForm) that will enforce this policy.
  • 13. SSL: What could go wrong?● Login pages (including the page hosting theform) must be secured● Never include insecure resources on asecure page (use "//").● Beware of third-party widgets on securesections of your site● Protect against downgrade attacks● If you can, implement Strict-Transport-Security
  • 14. "Were not storing credit cards"Are you sure? Are you storing this informationin PHP sessions?
  • 15. What can you do to protect yoursite?Theres a lot of ways an attacker can ruin yoursite, but fortunately theres a lot you can do tostop them.The big problem is understanding the risks andimplementing appropriate measures to protectyour site.
  • 16. Web Application Firewalls● Generally ineffective against motivatedattackers● "Great" at catching automated tools● Depending on your application, might beworth deploying, though they can breaknormal functionality if deployed incorrectly orwithout adequate testing● Some only detect problems, and dont blockthem● False positives can lead to a poor userexperience.
  • 17. apache2 mod_securitymod_security is a apache module that providesfiltering (blocking) and logging of potentialattacksEven if you dont use it to stop attacks, its greatto have some idea of whats happening on yoursite.
  • 18. Directory Permissions● Only grant read access to your code fromthe apache user● Store all user data outside of the webroot,and make sure it cannot be executed.● Set open_basedir.Beware of that "edit theme" or "edit code"feature in your favorite content managementsystem
  • 19. Administrative portalsIf you dont need the public to be able to getthem, secure beyond the applications built inauthentication measures.This could include a different virtualhost toaccess the administrative interface, or someother form of authentication.
  • 20. Backup files in webroot[user@host config] lsconfig.php.bak config.phpSolution: dont edit files on your productionserver, turn off creating backup files, or addappropriate access controls to prevent thesefiles from being accessed.
  • 21. Default setup filesSome programs are secure, but their setup filesinclude many security issues (phpmyadmin).Solution: Delete them!Bonus: if youre using shared hosting, makesure they dont have any of their own programs
  • 22. Implement the right HTTP Headers● X-Content-Type-OptionsStop the browser from detecting the type ofdocument (XSS)● X-XSS-ProtectionActivates IE8s XSS protection● X-Frame-OptionsHelps prevent clickjacking● Cache-ControlPrevent browsers (and proxies) from storingsensitive information
  • 23. Use HTML5 EffectivelyHTML5 adds a lof new functionality to theexisting HTML standard... and breaks your XSSprotections (actually they were broken already).Make use of the new HTML5 security featuresand do away with your filters (hint: ContentSecurity Policy)Know what your browser(s) do:
  • 24. Implement HTML5 Content SecurityPolicy!Idea: HTML filters wont catch everything, solets create a whitelist of resources.This policy allows images, scripts, AJAX, and CSS from thesame origin, and does not allow any other resources toload (eg object, frame, media, etc). It is a good startingpoint for many sites.default-src none; script-src self; connect-src:self; img-src: self; style-src: self;
  • 25. Watch for updates● 5.3.12, 5.3.13 and 5.3.14 - a 8 year oldsecurity issue was discovered.● "Top WordPress sites vulnerable 6 weeksafter plugin patch released"● Sometimes Zend Server has patches aheadof the official PHP release. Find out whatyour vendors update policy is.● Subscribe to mailing lists to get propernotification of updates.
  • 26. Setup a HoneypotIdea: set up some paths that are not part ofyour site that immediately alert you to activityExample (in robots.txt):Disallow: /my_cool_administratorIf you dont use /my_cool_administrator, thenthe only people going to it would be bots... thatpurposefully misuse robots.txt
  • 27. What tools do the attackers use?Just to name a few:● Nessus● sqlmap● w3af● OWASP ZAP● WPScan● Metasploit Framework● Beef Framework● burp suiteAll of these tools are straightforward to use. Alittle bit of experience can get you insight on thesecurity of your website
  • 28. Lets look at the tooks attackers use
  • 29. Most of the tools require the cookies of analready logged in user to performauthentication, through a mozilla "cookie jar"file.2. Rather than downloading all of thepreviously mentioned tools, you candownload Kali Linux or OWASP WTE andget up and ready to go in a few minutes.Some notes on using tools
  • 30. Before you use the tool, read theREADMEDont end up like this (via securityreactions)
  • 31. Where to go from here● Familiarize yourself with the OWASP top 10● Be aware of any security issues in yourlibraries. Do they assume data is alreadysecure, or do they handle it for you?● Create a software development strategy fortrusted or untrusted data, and the pointwhere it transitions from one to the other.● Setup appropriate logging setup todetermine the outcome of a successfulattack● Secure your server to slow down attackers
  • 32. Where to go from here● Ask for help when youre unsure (● Have someone else audit your site● Find out what security features the other topsites are using (like content security policy).● Subscribe to security mailing list(s)● Attend the Mozilla Training next week● Check out the OWASP Meetup Group
  • 33. Questions?
  • 34. Thanks!Andrew