Slide 1
Slide 1 text
Shiny
Let’s Be Bad Guys!
Exploiting and Mitigating the
Top 1
0 Web App Vulnerabilities
Mike Pirnat - @mpirnat
CodeMash 2017
Setup: https://github.com/mpirnat/lets-be-bad-guys
Slide 2
Slide 2 text
Announcements
• This session will run 1:00 PM – 5:00 PM
• We’ll break midway through
• Snacks & beverages available
• Feedback via EventsXD mobile app
• Slides linked from github repo
Setup: https://github.com/mpirnat/lets-be-bad-guys
Slide 3
Slide 3 text
Shiny
Let’s Be Bad Guys!
Exploiting and Mitigating the
Top 1
0 Web App Vulnerabilities
Mike Pirnat - @mpirnat
CodeMash 2017
Setup: https://github.com/mpirnat/lets-be-bad-guys
Slide 4
Slide 4 text
Who here makes
web apps?
Setup: https://github.com/mpirnat/lets-be-bad-guys
Slide 5
Slide 5 text
Who here has
vulnerable apps?
Setup: https://github.com/mpirnat/lets-be-bad-guys
Slide 6
Slide 6 text
Why it Matters
• Your users
• Your data
• Your business
Setup: https://github.com/mpirnat/lets-be-bad-guys
Slide 7
Slide 7 text
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
Setup: https://github.com/mpirnat/lets-be-bad-guys
Slide 8
Slide 8 text
OWASP Top Ten
• Based on risk data from 8 security firms
• Over 500,000 vulnerabilities, hundreds of
orgs, thousands of apps
• Selected & prioritized by prevalence data
combined with estimates of
exploitability, detectability, and impact
• Updated in 2013 (refresh coming in 2017)
Setup: https://github.com/mpirnat/lets-be-bad-guys
Slide 9
Slide 9 text
Today
• Background on a type of vulnerability
• Exploit it!
• Discuss prevention
• Django & Flask specific advice where
possible
• Light examples where we have time
Setup: https://github.com/mpirnat/lets-be-bad-guys
Slide 10
Slide 10 text
Disclaimer
Setup: https://github.com/mpirnat/lets-be-bad-guys
Slide 11
Slide 11 text
About Django
Setup: https://github.com/mpirnat/lets-be-bad-guys
Slide 12
Slide 12 text
About Flask
Setup: https://github.com/mpirnat/lets-be-bad-guys
Slide 13
Slide 13 text
Setup: 1
Make & activate a virtualenv:
Setup: https://github.com/mpirnat/lets-be-bad-guys
# Python 3...
$ pyvenv badguys
# Python 2...
$ virtualenv badguys
$ cd badguys
$ source bin/activate
# Python 3...
> pyvenv.py badguys
# Python 2...
> virtualenv badguys
> cd badguys
> Scripts/activate.bat
Slide 14
Slide 14 text
Setup: 2
Clone the repository:
$ git clone https://github.com/
mpirnat/lets-be-bad-guys src
Or pull the latest changes:
$ cd src
$ git pull
Setup: https://github.com/mpirnat/lets-be-bad-guys
Slide 15
Slide 15 text
Setup: 3
Install dependencies:
$ cd src
$ pip install -r requirements.txt
> cd src
> pip.exe install -r requirements.txt
Setup: https://github.com/mpirnat/lets-be-bad-guys
Slide 16
Slide 16 text
Setup: 4
Start up the app:
$ python manage.py runserver
Setup: https://github.com/mpirnat/lets-be-bad-guys
Slide 17
Slide 17 text
Find a Partner
Setup: https://github.com/mpirnat/lets-be-bad-guys
Slide 18
Slide 18 text
Injection
Slide 19
Slide 19 text
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
Slide 20
Slide 20 text
Who can you
trust?
Slide 21
Slide 21 text
Trust No One
• External users
• Internal users
• Administrators
Slide 22
Slide 22 text
Attack Vectors
• GET parameters
• POST parameters
• PATH_INFO
• Some HTTP headers: Cookie, Host
• Uploaded Files
Slide 23
Slide 23 text
Possible
Consequences
• Creation of malicious SQL (or other
queries)
• Accessing private files on disk
• Arbitrary code execution
Slide 24
Slide 24 text
Real-World
Examples
• Sony Playstation Network
• Ruby on Rails
• HBGary
• MySQL
• Many, many others…
Slide 25
Slide 25 text
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';
"""
• Use 2 dashes to start a SQL comment: --
• http://localhost:8000/injection/sql
Slide 26
Slide 26 text
Accessing
Private Files
• File system access + unvalidated user
input allows attackers to navigate the file
system
• http://localhost:8000/injection/file-
access
Slide 27
Slide 27 text
Arbitrary Code
Execution
• Unsafe input is dynamically evaluated
or executed
• http://localhost:8000/injection/code-
execution
Slide 28
Slide 28 text
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.
Slide 29
Slide 29 text
Django Advice
• Make sure data types for your model are
tight
• Use Forms instead of ModelForms
• Make new validators as needed for your
application
• Make sure your URL regexes for dynamic
URLs are tight
Slide 30
Slide 30 text
Django Advice
• Use the ORM when you can
• When you can’t, use extreme caution!
• Use bind variables/parameters
• No string concatenation/formatting of
anything that came from the client
Slide 31
Slide 31 text
Without the ORM
# If it's a basic select:
MyModel.objects.raw("SELECT ... WHERE foo = %s",
params={'foo': ...})
# If it's more complicated:
from django.db import connection
cursor = connection.cursor()
cursor.execute("UPDATE bar set bar = 1 WHERE foo < %s",
[foo])
row = cursor.fetchall()
Slide 32
Slide 32 text
Flask Advice
• Use Flask-WTF to validate form input
• Use SQLAlchemy
• Bind variables if you don’t
Slide 33
Slide 33 text
Broken
Authentication
& Session
Management
Slide 34
Slide 34 text
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
Slide 35
Slide 35 text
Possible
Consequences
• Compromised user accounts
• Compromised administrative accounts
• Unauthorized use of privileged
functionality
Slide 36
Slide 36 text
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
Slide 37
Slide 37 text
Django Advice
• Use django.contrib.auth
• Consider http://django-session-
security.readthedocs.io/ middleware for
timing out sessions
• We’ll talk about transport layer security
later on...
Slide 38
Slide 38 text
Flask Advice
• Use flask-security
• Read https://pythonhosted.org/Flask-
Security/
• Avoid overuse of cookies for storing
session state
Slide 39
Slide 39 text
Cross-Site
Scripting (XSS)
Slide 40
Slide 40 text
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
Slide 41
Slide 41 text
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)
Slide 42
Slide 42 text
Possible
Consequences
• Execute scripts in a victim’s browser
• Hijack sessions
• Deface sites
• Insert hostile content
• Redirect users
• Hijack browser (install malware)
Slide 43
Slide 43 text
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
Slide 44
Slide 44 text
Real-World
Example
• ESPN had a page that exposed
unsanitized content from the URL
• Able to replace the content of the page
• Used bit.ly to make an official-looking
short URL!
• http://es.pn/Z0jnoi
Slide 45
Slide 45 text
XSS in
Dynamic URLs
• Part of the URL path is variable, isn’t
validated, and gets included into the page:
http://example.com/stuff/{$CATEGORY}
• http://localhost:8000/cross-site-
scripting/path-matching/your-path-
here
Slide 46
Slide 46 text
XSS in Query
String Parameters
• Unvalidated user input from a query
string parameter is included in the page:
http://example.com/?search={$TEXT}
• http://localhost:8000/cross-site-
scripting/query-params?qs=awesome
Slide 47
Slide 47 text
XSS in
Form Fields
• The value part of an input is
prematurely terminated, allowing
Javascript to be injected into or adjacent
to the element:
• http://localhost:8000/cross-site-
scripting/form-field
Slide 48
Slide 48 text
Can you trust the
database?
Slide 49
Slide 49 text
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!
Slide 50
Slide 50 text
Prevention
• Use X-XSS-Prevention header to
configure browser XSS sanitization behavior
• Use X-Frame-Options header to control
whether and how a page can be loaded
within a frame
• Use Content-Security-Policy header to
specify where a page can load resources
from (requires careful tuning)
Slide 51
Slide 51 text
Django Advice
• Be careful with the safe filter,
django.utils.safestring, etc.
• Use form.as_p, form.as_table,
form.as_ul when displaying a form in a
template
• Be careful with your own template tags;
django.utils.html.escape is your friend!
Slide 52
Slide 52 text
django.utils.html
cleaned = escape(unsafe_value)
cleaned = escapejs(unsafe_value)
cleaned = strip_tags(unsafe_value)
cleaned = remove_tags(unsafe_value, ['script', ...])
Slide 53
Slide 53 text
Flask Advice
• Don’t disable autoescaping
• Be very careful with anything you
bless via Markup objects, the safe filter, or
blocks where autoescape is disabled
Slide 54
Slide 54 text
Insecure
Direct Object
References
Slide 55
Slide 55 text
Insecure Direct
Object Reference
• Expose a reference to an internal
implementation object without verifying
authorization
• Attacker changes URL, GET/POST
parameters, cookies
Slide 56
Slide 56 text
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
Slide 57
Slide 57 text
Exercises
• Manipulate parameters in the URL to
access data that doesn’t belong to you
• http://localhost:8000/direct-object-
references
Slide 58
Slide 58 text
Prevention
• Implement access controls on any direct
references to restricted resources
• Implement per-user or per-session
indirect object references
• This can be as much about URL design
as about access control!
Slide 59
Slide 59 text
Django + Flask
• Lock down views:
• Use Django’s permissions architecture
• Use Flask-Security or Flask-Login
• Customize Django queryset for looking
up objects that involve user ownership
Slide 60
Slide 60 text
Custom Queryset
# In models.py...
class ThingyManager(models.Manager):
def for_user(self, user):
return self.get_query_set().filter(user=user)
class Thingy(models.Model):
objects = ThingyManager()
# In views.py...
class ThingyUpdateView(UpdateView):
def get_queryset(self):
return Thingy.objects.for_user(
self.request.user)
Slide 61
Slide 61 text
Security
Misconfiguration
Slide 62
Slide 62 text
Security
Misconfiguration
• Insecure application settings
• Unpatched flaws
• Unused pages
Slide 63
Slide 63 text
Possible
Consequences
• Unauthorized access to some system
data or functionality
• Potential complete system compromise
Slide 64
Slide 64 text
Exercises
• Demos and discussion
• http://localhost:8000/misconfiguration
Slide 65
Slide 65 text
Text
This Really
Happens!
• Patreon compromised via exposed
Werkzeug Debugger
• https://labs.detectify.com/2015/10/02/
how-patreon-got-hacked-publicly-
exposed-werkzeug-debugger/
Slide 66
Slide 66 text
No content
Slide 67
Slide 67 text
No content
Slide 68
Slide 68 text
No content
Slide 69
Slide 69 text
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
Slide 70
Slide 70 text
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
• Don’t use the built-in admin for normal
user admin tasks
Slide 71
Slide 71 text
Flask Advice
• Read http://flask.pocoo.org/docs/
security
• Set app.debug = False to turn off
debugging
Slide 72
Slide 72 text
Gateway to Social
Engineering?
Slide 73
Slide 73 text
Sensitive
Data Exposure
Slide 74
Slide 74 text
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
Slide 75
Slide 75 text
Insecure
Cryptographic Storage
• Not encrypting worthy data
• Unsafe key generation & storage, failure
to rotate keys
• Weak algorithms
• Weak or unsalted hashes
Slide 76
Slide 76 text
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
Slide 77
Slide 77 text
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.
Slide 78
Slide 78 text
Possible
Consequences
• Expose individual users’ data
• Account theft
• Compromise an admin account?!
• Poor SSL setup can facilitate phishing
and man-in-the-middle attacks
Slide 79
Slide 79 text
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 (!!!)
Slide 80
Slide 80 text
http://cdn.ttgtmedia.com/digitalguide/images/Misc/WiresharkSS3_lg.png
Slide 81
Slide 81 text
http://echeng.com/journal/images/misc/firesheep.png
Slide 82
Slide 82 text
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
Slide 83
Slide 83 text
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
Slide 84
Slide 84 text
Prevention
•Use HTTP Strict Transport Security
(HSTS) header to protect against
downgrade attacks and cookie hijacking
•Consider setting Public Key Pinning
(HPKP) header to reduce impersonation
by attackers with mis-issued or fraudulent
certificates
Slide 85
Slide 85 text
Django Advice
• Use django.contrib.auth for proper password salting and
hashing
• Use bcrypt or Argon2; see https://
docs.djangoproject.com/en/1.10/topics/auth/
passwords/
• Require SSL in Apache or Nginx
• Require SSL using middleware:
• Configure Django SecurityMiddleware–introduced in Django 1.8!
• https://docs.djangoproject.com/en/1.10/ref/middleware/
• https://github.com/rdegges/django-sslify
Slide 86
Slide 86 text
Secure Cookies
# In your settings.py...
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True
Slide 87
Slide 87 text
Flask Advice
• Salt passwords using werkzeug.security:
• http://flask.pocoo.org/snippets/54/
• Require SSL:
• https://github.com/kennethreitz/flask-sslify
• https://github.com/jacobian/wsgi-sslify
• Use Passlib to do bcrypt or Argon2:
• https://passlib.readthedocs.io/en/stable/
Slide 88
Slide 88 text
Missing
Function Level
Access Control
Slide 89
Slide 89 text
Missing
Function Level
Access Control
• Application doesn’t protect its functions
properly
• Misconfiguration
• Forgot proper code checks
Slide 90
Slide 90 text
Attack Vectors
• Authorized user changes a URL or
parameter to a privileged function
• Anonymous users could access private
functions that aren’t protected
Slide 91
Slide 91 text
Possible
Consequences
• Compromised user accounts
• Compromised administrative accounts
• Unauthorized use of privileged
functionality
Slide 92
Slide 92 text
Exercises
• Manipulate the URL to access privileged
functionality
• http://localhost:8000/missing-access-
control
Slide 93
Slide 93 text
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
Slide 94
Slide 94 text
Django + Flask
• Lock down views:
• Use Django’s permissions architecture
• Use Flask-Security or Flask-Login
• Don’t use Django’s built-in admin for
normal user admin tasks
Slide 95
Slide 95 text
Cross-Site
Request Forgery
Slide 96
Slide 96 text
CSRF Attacks
• Cross-Site Request Forgery (CSRF)
• Attacker tricks victim into submitting
forged HTTP requests
• Attack succeeds if user is authorized/
authenticated
Slide 97
Slide 97 text
Attack Vectors
• Image tags
• Cross-Site Scripting (XSS)
• Fake buttons
• Phishing forms
• Other techniques
Slide 98
Slide 98 text
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...
Slide 99
Slide 99 text
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/
Slide 100
Slide 100 text
What if...
http://example.com/transferFunds?amount=…&destinationAccount=…
Slide 101
Slide 101 text
What if...
Slide 102
Slide 102 text
CSRF via Image
• Craft an “image” link that triggers some
site functionality
• http://localhost:8000/csrf/image
Slide 103
Slide 103 text
CSRF via
Form Post
• Create an innocuous-looking form that
POSTs to a vulnerable location
• http://localhost:8000/csrf/third-party-
site
Slide 104
Slide 104 text
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
Slide 105
Slide 105 text
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);
http://codrspace.com/vote539/csrf-
protection-in-django-tastypie/
Slide 106
Slide 106 text
Flask Advice
Various CSRF solutions...
• DIY/naïve: http://flask.pocoo.org/snippets/3/
• Flask-WTF: http://flask-wtf.readthedocs.org/
en/latest/csrf.html
• Flask-SeaSurf: https://flask-
seasurf.readthedocs.org/en/latest/
• Flask-csrf: http://sjl.bitbucket.org/flask-csrf/
Slide 107
Slide 107 text
Using Known
Vulnerable
Components
Slide 108
Slide 108 text
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
Slide 109
Slide 109 text
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
Slide 110
Slide 110 text
Possible
Consequences
• Full range of weaknesses are possible
• Impact could be minimal, or...
• Complete host takeover!
• Data compromise!
Slide 111
Slide 111 text
No content
Slide 112
Slide 112 text
No content
Slide 113
Slide 113 text
No content
Slide 114
Slide 114 text
No content
Slide 115
Slide 115 text
No content
Slide 116
Slide 116 text
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
Slide 117
Slide 117 text
Python Advice
• Use pip to find old packages:
pip list --outdated
• Use requires.io to monitor dependencies
Slide 118
Slide 118 text
Django + Flask
• Keep an eye on the mailing lists:
• https://groups.google.com/group/django-
announce
• http://flask.pocoo.org/mailinglist
• Follow @djangoproject on Twitter
Slide 119
Slide 119 text
Unvalidated
Redirects &
Forwards
Slide 120
Slide 120 text
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
Slide 121
Slide 121 text
Possible
Consequences
• Install malware
• Phishing/information disclosure
• Bypass access controls
Slide 122
Slide 122 text
External
Redirection
• Use a redirection URL to redirect to an
external location
• http://localhost:8000/redirects-and-
forwards/redirects
Slide 123
Slide 123 text
Forwards
• Manipulate a forward parameter to gain
access to privileged functionality
• http://localhost:8000/redirects-and-
forwards/forwards
Slide 124
Slide 124 text
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
Slide 125
Slide 125 text
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
Slide 126
Slide 126 text
Checking
Redirects
from django.shortcuts import redirect
from django.utils.http import is_safe_url
def my_view(request):
...
url = 'http://www.example.com/foo/bar'
if is_safe_url(url, host='www.example.com'):
return redirect(url)
else:
...
Slide 127
Slide 127 text
Allowing Multiple
Safe Hosts
from django.utils.http import is_safe_url
def is_whitelisted_url(url, hosts):
for host in hosts:
if is_safe_url(url, host=host):
return True
return False
>>> url = 'http://us.pycon.org'
>>> whitelist = ['us.pycon.org', 'pycon.org', ...]
>>> is_whitelisted_url(url, whitelist)
True
Slide 128
Slide 128 text
Flask Advice
• Redirect back: http://flask.pocoo.org/
snippets/62/
• Redirect back, more selectively with
whitelist, using cookies for previous URL:
http://flask.pocoo.org/snippets/120/
• Can modify these approaches to suit,
as with the Django example
Slide 129
Slide 129 text
Who here has
vulnerable apps?
Slide 130
Slide 130 text
Who is ready to
do something
about it?
Slide 131
Slide 131 text
Parting Thoughts
Slide 132
Slide 132 text
Think Like
a Bad Guy
Slide 133
Slide 133 text
Don’t Stop at Ten
Slide 134
Slide 134 text
Constant Change
Slide 135
Slide 135 text
Think Positive
Slide 136
Slide 136 text
Further
Exploration
• http://www.owasp.org
• https://www.owasp.org/index.php/OWASP_Top_Ten_Project
• https://www.owasp.org/index.php/OWASP_Secure_Headers_Project
• https://www.smashingmagazine.com/2016/09/content-security-
policy-your-future-best-friend/
• https://docs.djangoproject.com/en/dev/topics/security/
• http://flask.pocoo.org/docs/security
• OSCON 2016 & PyCon 2016: Security on a Shoestring
• https://www.fullstackpython.com/web-application-security.html
• https://github.com/mpirnat/lets-be-bad-guys
Slide 137
Slide 137 text
Contact Me
Mike Pirnat
http://mike.pirnat.com
@mpirnat
Tutorial feedback: EventsXD mobile app