1. Shiny,
Let’s Be Bad Guys!
Exploiting and Mitigating the
Top 1 Web App Vulnerabilities
0
Mike Pirnat - @mpirnat
David Stanek - @dstanek
Text

2. Announcements

3. Schedule & Lunch
• This session will run 9:00 AM - 12:20 PM
• 20-minute break at 10:50 AM
• Lunch 12:20 PM - 1:20 PM
• Lunch moved to Exhibit Hall D

4. Volunteering
Opportunities
• Low-commitment! Fun!
• SWAG bagging: Thursday 4-8 PM
• Just do 10 bags! (~1/2 hr)
• Registration Desk: any time
• 1-2 hours helps
• Friday => meet everyone!

5. Volunteering Info
• Current needs:
http://bit.ly/pycon-volunteering-status
• More information:
http://bit.ly/pycon2013-volunteer

6. Tutorial Feedback
• Go here:
• https://www.surveymonkey.com/s/
pycon2013_tutorials or
• https://goo.gl/PvHDc
• Be honest!

7. http://i.qkme.me/3r16r5.jpg

8. QWho here has
vulnerable apps?

9. Why it Matters
• Your users
• Your data
• Your business

10. OWASP
• http://www.owasp.org
• Open Web Application Security Project
• Non-profit focused on improving software
security
• Documentation and tools to help learn
about security and protect your apps

11. OWASP Top Ten
• Based on risk data from 8 firms
• Over 500,000 vulnerabilities, hundreds of
orgs, thousands of apps
• Selected & prioritized by prevalence data
combined with estimates of exploitability,
detectability, and impact
• Recently updated for 2013!

12. Today
• Background on a type of vulnerability
• Exploit it!
• Discuss prevention
• Django-specific advice where possible

13. Disclaimer

14. Setup: 1
Make a virtualenv:
$ virtualenv badguys
$ cd badguys
$ source bin/activate

15. Setup: 2
Clone our repository:
$ git clone https://github.com/
mpirnat/lets-be-bad-guys src
Or pull the latest changes:
$ cd src
$ git pull

16. Setup: 3
Install dependencies:
$ cd src
$ pip install -r requirements.txt

17. Setup: 2 & 3
(Offline/USB)
• Extract the project:
$ mkdir src
$ unzip /Volumes/BADGUYS/project/
badguys.zip -d src/
• Install dependencies:
$ cd src
$ pip install -r requirements.txt
-i file:///Volumes/BADGUYS/software

18. Setup: 4
Start up the app:
$ python manage.py runserver

19. Find a Partner

20. 1
Injection

21. Injection Attacks
• When an application sends untrusted data
to an interpreter
• Can result in data loss/corruption, lack of
accountability, denial of access
• Can lead to complete host takeover

22. Trust No One
• External users
• Internal users
• Administrators

23. Attack Vectors
• GET parameters
• POST parameters
• PATH_INFO
• Some HTTP headers: Cookie, Host
• Uploaded Files

24. Possible
Consequences
• Creation of malicious SQL (or other
queries)
• Accessing private files on disk
• Arbitrary code execution

25. Real-World
Examples
• Sony Playstation Network
• Ruby on Rails
• http://es.pn/Z0jnoi

26. SQL Injection
• Unescaped user input causes the premature
end of a SQL query and allows a malicious
query to be executed...
"""
select * from users where
username='%s';
"""
• http://localhost:8000/injection/sql

27. Accessing Private
Files
• File system access + unvalidated user
input allows attackers to navigate the file
system
• http://localhost:8000/injection/file-
access

28. Arbitrary Code
Execution
• Unsafe input is dynamically evaluated or
executed
• http://localhost:8000/injection/code-
execution

29. Prevention
• Validate ALL user input
• Sign cookies, don’t accept if signature is
bogus/missing
• Use ORMs or bind variables when talking
to the database
• Don’t use eval or exec, beware of pickle,
user-supplied YAML, etc.

30. Django Advice
• Make sure data types for your model are tight
• Use Forms instead of ModelForms for
stronger validation
• Make new validators as needed for your
application
• Make sure your URL regexes for dynamic
URLs are tight

31. Django Advice
• Use the ORM when you can
• When you can’t, use extreme caution!
• Bind variables
• No string concatenation/formatting of
anything that came from the client

32. 2 Broken
Authentication
& Session
Management

33. Broken Auth &
Session
Management
• Attacker uses leaks or flaws in
authentication or session management to
impersonate users
• Roll-your-own solutions contribute to the
difficulty of finding these flaws

34. Possible
Consequences
• Compromised user accounts
• Compromised administrative accounts
• Unauthorized use of privileged
functionality

35. Prevention
• Hash or encrypt passwords
• Don’t let credentials be easily overwritten
• Don’t put session IDs in URLs
• Allow session IDs to timeout/log out
• Rotate session IDs after successful login
• TLS connections for passwords, session IDs

36. Django Advice
• Use django.contrib.auth
• Consider https://github.com/yourlabs/
django-session-security middleware for
timing out sessions
• We’ll talk about transport layer security
later on...

37. 3 Cross-Site
Scripting (XSS)

38. XSS Attacks
• Cross-Site Scripting (XSS)
• The most prevalent web app security flaw
• App includes user-supplied data in content
sent to the browser without properly
validating or sanitizing it

39. XSS Attacks
• Stored: injected code permanently stored in
database, message forum, comment, etc.
• Reflected: injected code in live request to
server, reflected back in error message or
search result
• DOM: injected code in browser DOM
environment that causes scripts to run in
unexpected ways (eg, reading from URL)

40. Possible
Consequences
• Execute scripts in a victim’s browser
• Hijack sessions
• Deface sites
• Insert hostile content
• Redirect users
• Hijack browser (install malware)

41. Most Often Seen...
• Places where user-created text is
displayed to other users (comments,
messages)
• Form inputs where value is populated
with user-supplied data
• Script tags where user-supplied data is
populated into script variables

42. XSS in
Dynamic URLs
• Part of the URL path is variable, isn’t
validated, and gets included into the page
• http://localhost:8000/cross-site-
scripting/path-matching/your-path-
here

43. XSS in Query
String Parameters
• Unvalidated user input from a query string
parameter is included in the page
• http://localhost:8000/cross-site-
scripting/query-params?qs=awesome

44. XSS in
Form Fields
• The value part of an input is prematurely
terminated, allowing Javascript to be
injected into the element (eg, adding an
onclick)
• http://localhost:8000/cross-site-
scripting/form-field

45. Q
Can you trust the
database?

46. Prevention
• Escape all untrusted data based on the
HTML context the data will be placed into
• Whitelist input validation
• Consider auto-sanitization libraries for rich
content (eg, OWASP’s AntiSamy)
• Update your parents’/in-laws’ browsers!

47. Django Advice
• Be careful with the safe filter,
django.utils.safestring, etc.
• Be careful with your own template tags;
django.utils.html.escape is your friend!
• Use form.as_p, form.as_table,
form.as_ul

48. 4 Insecure
Direct Object
References

49. Insecure Direct
Object Reference
• Expose a reference to an internal
implementation object without verifying
authorization
• Attacker changes URL or GET/POST
parameters, cookies

50. Possible
Consequences
• Compromise of all data that can be
referenced by the vulnerable parameter
• Unless the namespace is sparse, an
attacker can easily access all available
data of that type

51. Exercises
• Manipulate parameters in the URL to
access data that doesn’t belong to you
• http://localhost:8000/direct-object-
references

52. Prevention
• Implement access controls on any direct
references to restricted resources
• Implement per-user or per-session
indirect object references

53. Django Advice
• Use permissions architecture to lock
down views
• Customize queryset for looking up objects
that involve user ownership

54. 5 Security
Misconfiguration

55. Security
Misconfiguration
• Insecure application settings
• Unpatched flaws
• Unused pages

56. Possible
Consequences
• Unauthorized access to some system
data or functionality
• Potential complete system compromise

57. Exercises
• Demos and discussion
• http://localhost:8000/misconfiguration

58. Prevention
• Have a repeatable hardening process
• Have a process for keeping on top of
updates and patches
• Architecture that provides secure
separation between components
• Periodic scans and audits

59. Django Advice
• Don’t run in debug mode in production
• Keep your SECRET_KEY secret!
• Keep Python code out of webserver’s root
• Don’t run admin publicly (if you can help it)
• Don’t use the built-in admin for normal
user admin tasks

60. Q
Gateway to Social
Engineering?

61. 6 Sensitive
Data Exposure

62. Sensitive Data
Exposure
• Failure to properly protect credit cards, tax
ids, authentication credentials, etc.
• Sensitive data deserves extra protection
such as encryption at rest or in transit,
special precautions when exchanged with
the browser

63. Insecure
Cryptographic
Storage
• Not encrypting worthy data
• Unsafe key generation & storage, failure to
rotate keys
• Weak algorithms
• Weak or unsalted hashes

64. Insufficient
Transport Layer
Protection
• May not authenticate, encrypt, and protect
the confidentiality and integrity of sensitive
network traffic
• May use weak algorithms
• May use expired or invalid certificates
• May use certificates incorrectly

65. Possible
Consequences
• Compromise of all data that should have
been encrypted
• This can be highly sensitive information:
credentials, credit cards, personal data,
health records, etc.

66. Possible
Consequences
• Expose individual users’ data
• Account theft
• Compromise an admin account?!
• Poor SSL setup can facilitate phishing
and man-in-the-middle attacks

67. Attack Vectors
• Attacker monitors network traffic of your
users
• Maybe in public places (Starbucks,
conference wi-fi, etc.)
• Maybe back end connections
• Maybe inside your network (!!!)

68. Prevention
• Encrypt sensitive data at rest
• Encrypt offsite backups; manage keys
separately
• Use strong standard algorithms, strong keys
• Hash passwords with strong standard algorithm
& use appropriate salt
• Protect passwords & keys from unauthorized
access

69. Prevention
• Require SSL for all sensitive pages; redirect
non-SSL requests to SSL
• Set the “secure” flag on sensitive cookies
• Use only strong SSL algorithms
• Ensure your cert is valid, not expired, not
revoked, and matches your domain
• SSL/encryption on the back end too

70. Django Advice
• Use django.contrib.auth for proper password
salting and hashing
• Require SSL in Apache or Nginx
• Require SSL using middleware:
• http://www.redrobotstudios.com/blog/2010/02/06/
requiring-https-for-certain-paths-in-django/
• http://djangosnippets.org/snippets/2833/
• http://djangosnippets.org/snippets/1467/

71. 7 Missing
Function Level
Access Control

72. Missing
Function Level
Access Control
• Application doesn’t protect its functions
properly
• Misconfiguration
• Forgot proper code checks

73. Attack Vectors
• Authorized user changes a URL or
parameter to a privileged function
• Anonymous users could access private
functions that aren’t protected

74. Possible
Consequences
• Compromised user accounts
• Compromised administrative accounts
• Unauthorized use of privileged
functionality

75. Exercises
• Manipulate the URL to access privileged
functionality
• http://localhost:8000/missing-access-
control

76. Prevention
• Consider every page; public or private?
• If authentication is required, make sure
that checks are in place
• If additional authorization is required,
make sure that checks are in place
• Deny all by default; explicitly grant access
to users or roles

77. Django Advice
• Use the permissions architecture to
lock down views
• Don’t use the built-in admin for normal
user admin tasks

78. 8 Cross-Site
Request Forgery

79. CSRF Attacks
• Cross-Site Request Forgery (CSRF)
• Attacker tricks victim into submitting
forged HTTP requests
• Attack succeeds if user is authorized/
authenticated

80. Attack Vectors
• Image tags
• Cross-Site Scripting (XSS)
• Fake buttons
• Phishing forms
• Other techniques

81. Possible
Consequences
• Cause victim to change any data the
victim is allowed to change
• Cause victim to perform any function the
victim is authorized to use
• Impact varies based on victim’s role
• Think of some possibilities...

82. Real-World
Examples
• Facebook:
http://amolnaik4.blogspot.com/
2012/08/facebook-csrf-worth-
usd-5000.html
• Google/Gmail:
http://cryptogasm.com/2012/02/does-
google-understand-csrf/

83. CSRF via Image
• Craft an “image” link that triggers some
site functionality
• http://localhost:8000/csrf/image

84. What if...
<img src="http://example.com/
transferFunds?amount=1500&
destinationAccount=attackersAcct#"
width="0" height="0" />

85. CSRF via
Form Post
• Create an innocuous-looking form that
POSTs to a vulnerable location
• http://localhost:8000/csrf/third-party-
site

86. Prevention
• Don’t “do” things on a GET
• Include a unique token in a hidden field
(often used in concert with a cookie)
• Validate token to make sure the request
is from on-site
• Avoid putting the token into a query string

87. Django Advice
• Don’t change the built-in settings!
• Do use the CSRF middleware and
template tag in forms
• Be VERY CAREFUL about deactivating it
(csrf_exempt decorator)
• Be careful about APIs (Tastypie, oauth)

88. 9
Using Known
Vulnerable
Components

89. Components
with Known
Vulnerabilities
• Libraries, frameworks, and other modules
almost always run with full privilege
• Hard to stay up to date on everything
• Do you even know all the components in
use, let alone their versions?
• Components with known problems can be
identified & exploited with automated tools

90. Attack Vectors
• Attacker identifies a weak component
through scanning or manual analysis
• Customize exploit as needed
• More difficult the deeper the component is
in the application

91. Possible
Consequences
• Full range of weaknesses are possible
• Impact could be minimal, or...
• Complete host takeover!
• Data compromise!

92. Prevention
• Don’t use components you don’t write
(unrealistic)
• Keep components up to date
• Identify all components and versions
• Monitor security of these components

93. Django Advice
When @jacobian says there are new
security releases for Django, upgrade!

94. 10
Unvalidated
Redirects &
Forwards

95. Redirection Abuse
• Attacker tricks user into visiting a URL that
redirects or forwards the request without
validating the redirect location
• Users prone to click because the link is to
a legitimate site

96. Possible
Consequences
• Install malware
• Phishing/information disclosure
• Bypass access controls

97. External
Redirection
• Use a redirection URL to redirect to an
external location
• http://localhost:8000/redirects-and-
forwards/redirects

98. Forwards
• Manipulate a forward parameter to gain
access to privileged functionality
• http://localhost:8000/redirects-and-
forwards/forwards

99. Prevention
• Don’t use redirects or forwards
• Don’t involve user-supplied data to build
the redirect location
• Ensure the supplied value is valid and
authorized for the user

100. Django Advice
• Use django.utils.http.is_safe_url to
check redirect URLs
• Used by django.contrib.auth internally
• Consider wrapping is_safe_url if you have
to allow other off-domain URLs

101. QWho here has
vulnerable apps?

102. Parting Thoughts

103. Think Like
a Bad Guy

104. Don’t Stop at Ten

105. Constant Change

106. Think Positive

107. Announcements
• Lunch—moved to Exhibit Hall D
• Feedback—https://goo.gl/PvHDc
• Volunteer:
http://bit.ly/pycon2013-volunteer
http://bit.ly/pycon-volunteering-status

108. Links
• http://www.owasp.org
• https://www.owasp.org/index.php/
Category:OWASP_Top_Ten_Project
• https://docs.djangoproject.com/en/dev/
topics/security/
• https://github.com/mpirnat/lets-be-bad-guys

109. Contact Us
Mike Pirnat
http://mike.pirnat.com
@mpirnat
David Stanek
http://traceback.org
@dstanek