1. Seattle PHP
Users Group:
Security
June 13th, 2013

2. Hello!
Andrew Sorensen
andrewsorensen.net
andrew@andrewsorensen.net
@AndrewX192

3. First, a few questions for you
1. Have you dealt with a successful attack on
your website?
2. Do you have a security response procedure
and development strategies to handle
security problems?
3. Do you have an intrusion detection system
or web application firewall deployed?
4. Are you using shared, managed, or
dedicated hosting?

4. A brief background
● PHP 5.2+ (2007)
● Zend Framework 1.x and some 2.x
● Sysadmin of Apache/Nginx/IIS production
systems at SMBs
● Main focus is security since about 2010.
● Intern at Leviathan Security Group (starting
June 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 website
can be of value when comprising another
individual.
● There are plenty of problems for developers
to deal with, and it's difficult to implement
measures against all of them.

6. Scenario: Abusing program input
1. You expected an integer, but I gave you a
string.
2. But there's no way to be sure of it (weak
typing) without checking explicitly (filter_var)
3. And you forgot to check it
4. So now anyone can do something they
shouldn't be able to.

7. Program Input's the issue, sure
We know program input can break our
program, 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 object
reference)

8. But it's not just program input
Not all security issues result in a compromise
(or even any indication of a page being
accessed) on your server.
Example: What happens if someone uses the
back button after they log out of your website?
Example: what can I see by looking at the
network traffic?

9. So what's 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 Robots
Fetch item number ____ from section ____ of rack number
____, and place it on the conveyor belt.
Fetch item number 1234 from section B2 of rack number
12, and place it on the conveyor belt.
Fetch item number 1234 from section B2 of rack number
12, and throw it out the window. Then go back to your
desk and ignore the rest of this form. and place it on the
conveyor belt.
https://github.com/search?p=3&q=extension%3Aphp+mysql_query+%24_GET&ref=searchresults&type=Code

11. Cross Site Scripting (XSS)
<input name="search" type="search" value="
test" onmouseover="alert('xss');"/>
If *one* page of your site has an XSS
vulnerability, chances are your entire site is at
risk.
Escaping is great, if you can remember to do it
*everywhere* and you don't require rich text.

12. Cross site request forgery
Hello bank.com, Hello! I'm evil.com and I'd like
to send this information under the currently
logged in user? Oh sure. I'll handle that.
Solution: Use a CSRF token on every form
Better yet, find a framework or library (like
ZendForm) that will enforce this policy.

13. SSL: What could go wrong?
● Login pages (including the page hosting the
form) must be secured
● Never include insecure resources on a
secure page (use "//example.com/example.
js").
● Beware of third-party widgets on secure
sections of your site
● Protect against downgrade attacks
● If you can, implement Strict-Transport-
Security

14. "We're not storing credit cards"
Are you sure? Are you storing this information
in PHP sessions?

15. What can you do to protect your
site?
There's a lot of ways an attacker can ruin your
site, but fortunately there's a lot you can do to
stop them.
The big problem is understanding the risks and
implementing appropriate measures to protect
your site.

16. Web Application Firewalls
● Generally ineffective against motivated
attackers
● "Great" at catching automated tools
● Depending on your application, might be
worth deploying, though they can break
normal functionality if deployed incorrectly or
without adequate testing
● Some only detect problems, and don't block
them
● False positives can lead to a poor user
experience.

17. apache2 mod_security
mod_security is a apache module that provides
filtering (blocking) and logging of potential
attacks
Even if you don't use it to stop attacks, it's great
to have some idea of what's happening on your
site.

18. Directory Permissions
● Only grant read access to your code from
the 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 management
system

19. Administrative portals
If you don't need the public to be able to get
them, secure beyond the application's built in
authentication measures.
This could include a different virtualhost to
access the administrative interface, or some
other form of authentication.

20. Backup files in webroot
[user@host config] ls
config.php.bak config.php
Solution: don't edit files on your production
server, turn off creating backup files, or add
appropriate access controls to prevent these
files from being accessed.

21. Default setup files
Some programs are secure, but their setup files
include many security issues (phpmyadmin).
Solution: Delete them!
Bonus: if you're using shared hosting, make
sure they don't have any of their own programs

22. Implement the right HTTP Headers
● X-Content-Type-Options
Stop the browser from detecting the type of
document (XSS)
● X-XSS-Protection
Activates IE8's XSS protection
● X-Frame-Options
Helps prevent clickjacking
● Cache-Control
Prevent browsers (and proxies) from storing
sensitive information

23. Use HTML5 Effectively
HTML5 adds a lof new functionality to the
existing HTML standard... and breaks your XSS
protections (actually they were broken already).
Make use of the new HTML5 security features
and do away with your filters (hint: Content
Security Policy)
Know what your browser(s) do:
http://html5sec.org/

24. Implement HTML5 Content Security
Policy!
Idea: HTML filters won't catch everything, so
let's create a whitelist of resources.
This policy allows images, scripts, AJAX, and CSS from the
same origin, and does not allow any other resources to
load (eg object, frame, media, etc). It is a good starting
point 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 old
security issue was discovered.
● "Top WordPress sites vulnerable 6 weeks
after plugin patch released"
● Sometimes Zend Server has patches ahead
of the official PHP release. Find out what
your vendor's update policy is.
● Subscribe to mailing lists to get proper
notification of updates.

26. Setup a Honeypot
Idea: set up some paths that are not part of
your site that immediately alert you to activity
Example (in robots.txt):
Disallow: /my_cool_administrator
If you don't use /my_cool_administrator, then
the only people going to it would be bots... that
purposefully 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 suite
All of these tools are straightforward to use. A
little bit of experience can get you insight on the
security of your website

28. Let's look at the tooks attackers use

29. https://addons.mozilla.org/en-us/firefox/addon/export-cookies/
1. Most of the tools require the cookies of an
already logged in user to perform
authentication, through a mozilla "cookie jar"
file.
2. Rather than downloading all of the
previously mentioned tools, you can
download Kali Linux or OWASP WTE and
get up and ready to go in a few minutes.
Some notes on using tools

30. Before you use the tool, read the
README
Don't 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 your
libraries. Do they assume data is already
secure, or do they handle it for you?
● Create a software development strategy for
trusted or untrusted data, and the point
where it transitions from one to the other.
● Setup appropriate logging setup to
determine the outcome of a successful
attack
● Secure your server to slow down attackers

32. Where to go from here
● Ask for help when you're unsure (security.
stackexchange.com)
● Have someone else audit your site
● Find out what security features the other top
sites 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 Sorensen
andrewsorensen.net
andrew@andrewsorensen.net
@AndrewX192