Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Web App Security

No description
by

j y

on 6 February 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Web App Security

Data Exposure
Technical
:
Configurations
Versions of software
Where data is stored
Errors!!!
Other Attacks
Template Injection
Unvalidated Input
Most new developers forget this
Remote Code Execution (RCE)
Jackpot!!!
Why You Need to Know
Big Companies:
Security team won't hate you
Web App Security
Denial of Service
Denial of Service
(DoS - DDoS)
Application & Network Level
Unvalidated Input
Data Exposure
Remote Code Execution
Small Companies:
Won't ruin the business
Rules of Thumb
DO NOT

roll your own crypto
DO NOT
trust user input
DO NOT
rely on tests
DO
have a sysadmin
Limited amount you can do if network attack
When writing your application:
Tests can help
Make sure you have redundancies & monitoring for stuck/crashed systems
Consider the Chaos Monkey
(That's why you have a dedicated sysadmin!)
Wide variety of possibilities,
technical & personal
Personal:
Emails, usernames, addresses
Hours of activity or operations
Customer service
RCE means you're pwn3d -
hard
Most often found in your OS or
dependencies
Ruby (Rails), Node (Express), Java (serialization!)

If you save user files or in any way evaluate user input as code:
heavily examine that process
You Know This One
EVERYTHING SENT TO YOU IS SUSPECT!!
Cross Site Scripting
(XSS)
We all know this one:
Attacker runs JS
Steals auth data or does something pernicious
What else is caused by improper sanitizing?
SQL Injection
Unvalidated Forwarding
Cross Site Request Forgery (CSRF)
Missing Access Control Mechanisms
Missing Access Control
Unvalidated Forwarding
Template Injection
Database Injection
Cross Site Request Forgery (CSRF)
Mitigations
Hire an expert!
A good sysadmin will help you have a redundant, failure-resistant application architecture
You will need someone higher up the network stack (aka DNS, upper-Tier providers) to handle a large-scale DDoS
Mitigations
Follow industry best practices
This will vary with your specific field
Be mindful of any data leakage
Include phone/email interactions
Logging goes to engineers, not users
Check your physical space
Are screens locked?
Could a pizza delivery person find a password or client information?
Special Considerations
PCI Compliance (Credit Cards)
Healthcare Data
Other Financial or Personal Data
Confidential Information
Often
LEGALLY
required to meet certain standards:
mandatory audits
network isolation
encryption protocols
time-sensitive storage
Mitigations
Hire an expert!
Likely to be found during audits or penetration testing, let them help you resolve the issue
Fix/patch/block and notify your users
immediately
, live RCE means you have likely experienced a serious breach
Subscribe to security lists and watch for CVEs affecting your software stack - sysadmins help here
Isolate, sandbox, jail, minimum privileges, and an Intrusion Detection System (IDS)
Similar to XSS
But in your
template syntax
Could also be called
DSL injection
(we'll come back to this)
<
div

class
=
"user-display"
>
<
span

class
=
"username"
>
{{username}}
</
span
>
<
span

class
=
"user-text"
>
<
!-- user enters text saved here --
>
</
span
>
</
div
>
Angular Example
What happens if a user enters:
{{7*7}}
Often called SQL injection, the concept may be applied to any database
Specifically, the concept applies to any
D
omain
S
pecific
L
anguage
You wouldn't let any user stick code into your application,
right?
SELECT

[[user-input]]

FROM

public_data
SQL Example
*

FROM

private
;
DROP TABLE

users

--
What if our user enters:
This you're probably familiar with
Every link you follow through
Slack
,
Facebook
Twitter
etc...
By itself,
rarely a problem
But can aid phishing, scams, and some multi-part attacks
In some cases, can bypass filters or authorization checks!
Only checking referrer? See previous attack
aka
Security through Obscurity
or
Developer forgot to Auth
Authorization & Authentication
You'd be amazed how many things will work if you ignore the intended interface
Confirming that action? Hackers can automate
Authorized to
See
!= Authorized to
Modify
Authenticated by a 3rd party? Wider attack surface
Authenticated?
You know who is connected
Authorized?
The person allowed to do it
Client-side checks are UI-only
Often works through a combination of the previous methods
As you make it easier for your users to do things (add a post, change a setting), you make it easier for an attacker too
User_w/Token tweets
Server ok!
User_w/Token
on malicious page
malicious page serves JS that posts racist tweet
Attack successful!
Normal use
Normal browsing
CSRF in progress
Include extra verification - at endpoints and
from the server
. Don't expect attackers to use your interface
Mitigations
Take advantage of
automated tools
and lists of
common attack strings
Stay up-to-date on your framework's
security notifications
Regularly
test your application manually
- you, the developer, should be
intimately familiar
with the
data and execution flow
Abuse your interface
, hit the edges, put in bad or malicious data,
make sure you don't leak
information an attacker can use
Ignore the interface and
craft your own requests
, an attacker will!
Full transcript