Security Ninjas: An Open Source Application Security Training Program

* CONFIDENTIAL

Shru% Gupta Applica%on Security Engineer, OpenDNS

Security Ninjas Applica%on Security Training Program

Agenda

Most Common AppSec Mistakes + Hack Lab

Best Prac%ces

Q/A

Swag

Setup

Firefox

FoxyProxy

Burp Suite

Docker container or Web server instance

Agenda

Most Common Mistakes + Hack Lab

Best Prac%ces

Q/A

Swag

#1 Injec6on

▪  What is it?

#1 Injec6on

#1 Injec6on

#1 Injec6on

▪  What is it?

–  Untrusted data is sent to an interpreter –  command / query –  headers –  cookies –  {.. any other form of input ..}

–  Interpreter is tricked into execu6ng unintended commands

#1 Injec6on

▪  What all is suscep%ble? –  SQL –  Hadoop –  SOAP –  XML –  {..Anything..}

#1 Injec6on

▪  Why does it happen?

‒  Use of interpreters doesn’t clearly separate untrusted data from commands

‒  Lack of input valida6on/ sani6za6on ‒  AWacker is able to change execu%on context

#1 Injec6on

▪  Basic SQLi example

SELECT UserId, Name, Password FROM Users WHERE UserId = 105 or 1=1

#1 Injec6on

▪  How to prevent it? -  Use APIs that provide parameterized / sani%zed

interfaces -  Validate input against whitelist -  DON’T use a blacklist -  Escape special characters which you had to whitelist

#2 Broken Authen6ca6on & Session Management

▪  Weak Authen%ca%on logic ▪  Imperfect implementa%on ▪  Insufficient protec%on of session token ▪  Etc.


▪  How to prevent it?

-  Use strong algorithms to generate (random) secrets -  Protect secrets throughout their lifecycle -  Consider having centralized authen%ca%on and session

management APIs -  Implement strong account management func6ons (e.g., account

crea%on, change password, recover password, etc.) -  Protect against XSS


▪  Authen%ca%on bypass example

#3 Cross-‐Site Scrip6ng (XSS)

▪  What is it? -  Applica%on takes untrusted data -  Sends it to web browser without proper valida6on

and encoding -  Allows aPackers to execute scripts in the vic6m’s

browser -  hijack user sessions -  deface web sites -  redirect user to malicious sites -  etc.


▪  Types of XSS –  Reflected –  Stored –  DOM based

#3 Reflected Cross-‐Site Scrip6ng (XSS)

▪  Injected script is instantly reflected off the web server ‒  error message ‒  search result ‒  any other response that includes some or all of the input sent

▪  Delivered via another route to the vic%m

-  email, other website, etc.

#3 Reflected Cross-‐Site Scrip6ng (XSS)

▪  Example:

hWp://example.com/index.php?user=<script>alert(123);</script>

#3 Stored Cross-‐Site Scrip6ng (XSS)

▪  Injected script is permanently stored on target servers -  database -  message forum -  visitor logs -  comment fields

▪  Vic%m then retrieves malicious script from the server when he requests the stored informa%on

▪  Examples -  Forums -  Kibana search interface for Elas%csearch


▪  How to prevent XSS? ‒  Input valida%on ‒ Context based output encoding hWps://www.owasp.org/index.php/XSS_(Cross_Site_Scrip%ng)_Preven%on_Cheat_Sheet

‒ Content Security Policy ?

#4 Insecure Direct Object References

▪  Reference to internal implementa%on object is exposed ▪  e.g., file, directory, database key, etc. ▪  Lack of access controls/ other protec6ons ▪  AWackers can manipulate these references to access unauthorized data


▪  Example: ▪  Anyone can access any file uploaded on HipChat if he has the URL


▪  How to prevent it? -  Verify user is authorized to access the exact resource they have

requested -  If the reference is an indirect reference, does mapping to the

direct reference fail to limit the values to those authorized for the current user?

#5 Security Misconfigura6on

▪  Can be anywhere in the tech stack ‒  planorm ‒  web server ‒  database ‒  framework ‒  etc.

▪  Collec%ve effort between devs and Infra


▪  Example: ‒  default user account is not removed ‒  script kiddie runs automated tool ‒  tools can easily detect this ‒  dang!


▪  How to prevent it? ‒  Security hardening throughout Applica6on Stack ‒  Unnecessary features enabled or installed? ‒  Secure values not set? ‒  Default accounts/ passwords s%ll enabled or unchanged? ‒  Overly informa6ve error messages to users? ‒  Sopware out of date?

#6 Sensi6ve Data Exposure

▪  Client side -  hardcoded secrets, cache, headers, excep%ons, ..

▪  In transit -  SSL problems, MITM, ..

▪  Server side -  weak crypto/ keys/ hashes, insufficient DB protec%on, ..


▪  FB access token example


▪  How to prevent it? ‒  Determine what data needs to be protected and how much ‒  Use strong crypto algos/ keys / modes / passwords ‒  Don’t store data unnecessarily ‒  Turn off autocomplete on forms and caching ‒  Encrypt all sensi6ve data at rest and transit (internally & externally) ‒  Control access to sensi%ve data

#7 Missing Func6on Level Access Control

▪  Making sure only the right people have access to the right func%ons ▪  Func%ons may be called through

‒  URL parameters ‒  REST style URLs ‒  etc.?


▪  Facebook 12k bug bounty which let anyone delete images


▪  How to prevent it? ‒  Hiding func%onality from the UI won’t help ‒  Server side Authen6ca6on and Access Control checks ‒  Server side checks shouldn’t solely rely on informa%on provided by client ‒  Deny by default ‒  Central authoriza%on module ? ‒  Rate limi%ng?

#8 Cross-‐Site Request Forgery (CSRF)

▪  APacker can formulate all HTTP parameters for a request ▪  Browsers send session cookies automa%cally ▪  AWacker tricks end user into execu6ng unwanted ac6ons on a web applica%on in which he/she is currently authen6cated

▪  Target: state changing func%ons



▪  Example:

<img src="hWp://example.com/app/transferFunds? amount=1500&des%na%onAccount=aWackersAcct#“ width="0" height="0" />


▪  Myth : Mul%step transac%ons are immune to CSRF ▪  AWackers can easily forge a series of requests by using mul%ple tags or possibly JavaScript


▪  How to prevent it? ‒  Add unpredictability ‒  Unique random token ‒  CAPTCHA ‒  2 factor confirma%on

▪  There are OWASP libraries you can use e.g., CSRF Guard

#9 Using Components with Known Vulnerabili6es

▪  Applica%on/Tech Stack uses vulnerable components ‒  Frameworks ‒  Libraries ‒  Servers ‒  OSes ‒  other components


▪  Easy exploita%on using tools like Metasploit


▪  How to prevent it? ‒  Keep a check on vulnerabili%es that come out

‒  CVE ‒  Mailing lists

‒  Calculate risk ‒  Upgrade vulnerable components

#10 Unvalidated Redirects and Forwards

▪  Applica%on takes input from user ▪  Uses it to formulate Redirect/ Forward loca%on without input

valida%on ▪  AWacker misuses this for malicious redirec%ons/ forwarding


▪  AWack scenarios: ‒  Malware installa%on ‒  Phishing ‒  Access Control bypass

▪  e.g., ▪  hWps://login.opendns.com/umbrella/?return_to=hWps://dashboard2.opendns.com/

▪  hWps://login.opendns.com/umbrella/?return_to=hWps://dashboard2.opemdns.com/


▪  How to prevent it? ‒  Avoid using user input to determine des%na%on URL ‒  Whitelist allowed pages or external sites ‒  Ensure URL is valid and authorized for the user

Setup

Destroy your Docker container/stop the Webserver running the vulnerable applica%on

Agenda

Most Common Mistakes + Hack Lab

Best Prac%ces

Q/A

Swag

Security Planning

▪  Involve the Security team when planning a big feature / product

▪  Have Security features or controls added to User Stories when planning

Using 3rd Party Code

▪  What to do when using:

–  Security Libraries –  Other Libraries

Defense in Depth

▪  Why is it important? -  fail overs -  edge cases -  adding more fric%on for aWackers

Keep Sohware, Technologies etc. updated

▪  Why is it important? ‒  BePer and more features ‒  Security vulnerabili6es get patched in newer versions ‒  Newer versions get the most aPen6on ‒  Old ones stop gevng support ‒  Turn on auto updates for Chrome ‒  Look at updates on the AppStore

Use Hard Passwords

▪  Why is it important? ‒  Brute forcing passwords ‒  Dic%onary based aWacks ‒  Hash cracking

▪  Use a password manager

▪  Password Manager for shared accounts

▪  Reset when someone leaves

Be Minimalis6c

▪  Principle of Least Privilege ‒  Employee termina%on ‒  Mistakes ‒  Vulnerabili%es in other S/W which leverage this

▪  Don’t install redundant sohware, plugins, etc. -  Maintenance issues -  People forget to uninstall them -  Don't get much aWen%on from the community -  Open ports/ services

Don’t Hardcode Secrets in Source Code

▪  Put them in a config file ▪  Keep that in a secure place ▪  Restrict access to it

Input Valida6on

▪  Why is it important? ‒  Input coming from outside the trust boundary ‒  Clean it on the first point of entry ‒  Future dependencies more secure ‒  If reusing some user input from db/ internal storage, sani6ze it as

per your program’s context ‒  Mul%ple orders of Injec%on

Error Handling

▪  Why is it important?

▪  Least informa%on disclosure

Logging and Aler6ng

▪  Why is it important? ‒  Iden%fy threats ‒  Inves%ga%ons ‒  Mi%gate problems before they become too big ‒  Good also from func%onality and QA standpoint

*

Shru% Gupta shru%@opendns.com

Ques6ons?

Date post:	14-Jul-2015
Category:	Technology
Upload:	opendns
View:	2,333 times
Download:	2 times

Security Ninjas: An Open Source Application Security Training Program

Technology