Class: BE-IT

Semester: VII
Subject: Secure Application Development Lab

Experiment – 1: Study various standards of Cyber Security

Aim: To study of different laws and standards of Cyber Security.
Objectives: After study of this experiment, the student will be able to
• Understand different cyber security laws.
• Identify and learn different standards of cyber security.
Outcomes: After study of this experiment, the student will be able to
• Demonstrate knowledge of different laws and standards of cyber security.

Prerequisite: Programming concepts, Cyber security.

Requirements: PC and Internet
1. Pre experiment Theory
Brief Theory:
Cyber Security Introduction
Cyber security is the most concerned matter as cyber threats and attacks are overgrowing.
Attackers are now using more sophisticated techniques to target the systems. Individuals,
small-scale businesses or large organization, are all being impacted. So, all these firms whether
IT or non-IT firms have understood the importance of Cyber Security and focusing on adopting
all possible measures to deal with cyber threats.
What is cyber security?
“Cyber security is primarily about people, processes, and technologies working
together to encompass the full range of threat reduction, vulnerability reduction,
deterrence, international engagement, incident response, resiliency, and recovery
policies and activities, including computer network operations, information
assurance, law enforcement, etc." OR
Cyber security is the body of technologies, processes, and practices designed to
protect networks, computers, programs and data from attack, damage or
unauthorized access
• The term cyber security refers to techniques and practices designed to
protect digital data.
• The data that is stored, transmitted, or used on an information system.
OR Cyber security is the protection of Internet-connected systems, including
hardware, software, and data from cyber-attacks
It is made up of two words one is cyber and other is security
 • Cyber is related to the technology which contains systems, network and programs or
data
• Whereas security related to the protection which includes systems security,
network security and application and information security
Why is cyber security important?
Listed below are the reasons why cyber security is so important in what’s become a
predominant digital world.
1. Cyber-attacks can be extremely expensive for businesses to endure. In addition to
financial damage suffered by the business, a data breach can also inflict untold
reputational damage.
2. Cyber-attacks these days are becoming progressively destructive. Cybercriminals are
using more sophisticated ways to initiate cyber-attacks
Regulations such as GDPR are forcing organizations into taking better care of the personal data
they hold. Because of the above reasons, cyber security has become an important part of the
business and the focus now is on developing appropriate response plans that minimize the
damage in the event of a cyber-attack.
Types of Cyber Attacks
A cyber-attack is an exploitation of computer systems and networks. It uses malicious code to
alter computer code, logic or data and lead to cybercrimes, such as information and identity
theft.
Cyber-attacks can be classified into the following categories:
1) Web-based attacks
2) System-based attacks
Web-based attacks
These are the attacks which occur on a website or web applications. Some of the important
web-based attacks are as follows
1. Injection attacks
It is the attack in which some data will be injected into a web application to manipulate the
application and fetch the required information. Example- SQL Injection, code Injection, log
Injection, XML Injection etc.
2. DNS Spoofing
DNS Spoofing is a type of computer security hacking. Whereby a data is introduced into a
DNS resolver's cache causing the name server to return an incorrect IP address, diverting traffic
to the attackers computer or any other computer. The DNS spoofing attacks can go on for a
long period of time without being detected and can cause serious security issues.
3. Session Hijacking
It is a security attack on a user session over a protected network. Web applications create
cookies to store the state and user sessions. By stealing the cookies, an attacker can have access
to all of the user data.
4. Phishing
 Phishing is a type of attack which attempts to steal sensitive information like user login
credentials and credit card number. It occurs when an attacker is masquerading as a trustworthy
entity in electronic communication.
5. Brute force
It is a type of attack which uses a trial and error method. This attack generates a large number
of guesses and validates them to obtain actual data like user password and personal
identification number. This attack may be used by criminals to crack encrypted data, or by
security, analysts to test an organization's network security.
6. Denial of Service
It is an attack which meant to make a server or network resource unavailable to the users. It
accomplishes this by flooding the target with traffic or sending it information that triggers a
crash. It uses the single system and single internet connection to attack a server. It can be
classified into the following
Volume-based attacks- Its goal is to saturate the bandwidth of the attacked site, and is measured
in bit per second.
• Protocol attacks- It consumes actual server resources, and is measured in a packet.
Application layer attacks- Its goal is to crash the web server and is measured in request per
second.
7. Dictionary attacks
This type of attack stored the list of a commonly used password and validated them to get
original password.
URL Interpretation
It is a type of attack where we can change the certain parts of a URL, and one can
make a web server to deliver web pages for which he is not authorized to browse.
7. File Inclusion attacks
It is a type of attack that allows an attacker to access unauthorized or essential files which is
available on the web server or to execute malicious files on the web server by making use of
the include functionality.
8. Man in the middle attacks
It is a type of attack that allows an attacker to intercepts the connection between client and
server and acts as a bridge between them. Due to this, an attacker will be able to read, insert
and modify the data in the intercepted connection.
System-based attacks
These are the attacks which are intended to compromise a computer or a computer network. Some
of the important system-based attacks are as follows
1. Virus
It is a type of malicious software program that spread throughout the computer files without
the knowledge of a user. It is a self-replicating malicious computer program that replicates by
inserting copies of itself into other computer programs when executed. It can also execute
instructions that cause harm to the system.
2. Worm
It is a type of malware whose primary function is to replicate itself to spread to uninfected
computers. It works same as the computer virus. Worms often originate from email attachments
that appear to be from trusted senders.
3. Trojan horse
It is a malicious program that occurs unexpected changes to computer setting and unusual
activity, even when the computer should be idle. It misleads the user of its true intent. It appears
to be a normal application but when opened/executed some malicious code will run in the
background.
4. Backdoors
It is a method that bypasses the normal authentication process. A developer may create a
backdoor so that an application or operating system can be accessed for troubleshooting or
other purposes.
5. Bots
A bot (short for "robot") is an automated process that interacts with other network

services. Some bots program run automatically, while others only execute commands when
they receive specific input. Common examples of bots program are the crawler, chatroom bots,
and malicious bots
2. Laboratory Exercise Procedure
Study and explain various laws of cyber security
Write various standard of cyber security

3. Post-Experiments Exercise
A. Extended Theory:
Describe statistics of main vulnerabilities
.
B. Questions:
1. What are the different types of attacks?
2. What do you understand by cyber attack?

C. Conclusion:
1. Write what was performed in the experiment.
2. Write the significance of the topic studied in the experiment.

D. References:
1. https://mrcet.com/pdf/Lab%20Manuals/IT/CYBER%20SECURITY%20(R18A0521).pdf
2. Cyber Security Essentials, James Graham, Richard Howard and Ryan Otson, CRCPress.
3. Introduction to Cyber Security, Chwan-Hwa(john) Wu,J. David Irwin, CRC Press T&F Group
Class: BE-IT
Semester: VII
Subject: Secure Application Development Lab

Experiment – 2: To learn Case study for SDLC

Aim: To learn Case study for SDLC.
Objectives: After study of this experiment, the student will be able to
• Understand different steps of SDLC .
Outcomes: After study of this experiment, the student will be able to
• Demonstrate knowledge of different stages SDLC .

Prerequisite: Cyber security, software engineering

Requirements: PC and Internet

1. Pre-Experiment Exercise:

Brief Theory:

What Is Secure SDLC and Why Is Important ?

Security System Development Life Cycle (SecSDLC) is defined as the set of procedures that
are executed in a sequence in the software development cycle (SDLC). It is designed such that
it can help developers to create software and applications in a way that reduces the security
risks at later stages significantly from the start. The Security System Development Life Cycle
(SecSDLC) is similar to Software Development Life Cycle (SDLC), but they differ in terms of
the activities that are carried out in each phase of the cycle. SecSDLC eliminates security
vulnerabilities. Its process involves identification of certain threats and the risks they impose
on a system as well as the needed implementation of security controls to counter, remove and
manage the risks involved. Whereas, in the SDLC process, the focus is mainly on the designs
and implementations of an information system.
Phases involved in SecSDLC are:
• System Investigation: This process is started by the officials/directives working at the
top level management in the organization. The objectives and goals of the project are
considered priorly in order to execute this process. An Information Security Policy is
defined which contains the descriptions of security applications and programs installed
along with their implementations in organization’s system.
• System Analysis: In this phase, detailed document analysis of the documents from the
System Investigation phase are done. Already existing security policies, applications
and software are analyzed in order to check for different flaws and vulnerabilities in the
 system. Upcoming threat possibilities are also analyzed. Risk management comes under
this process only.
• Logical Design: The Logical Design phase deals with the development of tools and
following blueprints that are involved in various information security policies, their
applications and software. Backup and recovery policies are also drafted in order to
prevent future losses. In case of any disaster, the steps to take in business are also
planned. The decision to outsource the company project is decided in this phase. It is
analyzed whether the project can be completed in the company itself or it needs to be
sent to another company for the specific task.
• Physical Design: The technical teams acquire the tools and blueprints needed for the
implementation of the software and application of the system security. During this
phase, different solutions are investigated for any unforeseen issues which may be
encountered in the future. They are analyzed and written down in order to cover most
of the vulnerabilities that were missed during the analysis phase.
• Implementation: The solution decided in earlier phases is made final whether the
project is in-house or outsourced. The proper documentation is provided of the product
in order to meet the requirements specified for the project to be met. Implementation
and integration process of the project are carried out with the help of various teams
aggressively testing whether the product meets the system requirements specified in the
system documentation.
• Maintenance: After the implementation of the security program it must be ensured that
it is functioning properly and is managed accordingly. The security program must be
kept up to date accordingly in order to counter new threats that can be left unseen at the
time of design.

2. Laboratory Exercise
Procedure
Study any of the case study from references and the difference between software development
life cycle and security development life cycle

3. Post-Experiments Exercise
A. Extended Theory:
1. Describe how secure coding can be incorporated into the software development
process.
2. List the major types of coding errors and their root cause.
3. Describe good software development practices and explain how they impact
application security.
B. Questions:
1. List and discuss Secure SDLC Best Practices
C. Conclusion:
1. Write what was performed in the experiment.
2. Write the significance of the topic studied in the experiment.
D. References:
• Case study 1: https://quod.lib.umich.edu/j/jsais/11880084.0001.103/--case-study-of-
the-application-of-the-systems-development?rgn=main;view=fulltext
• Case study 2: https://onlinelibrary.wiley.com/doi/epdf/10.1002/sec.1700
https://snyk.io/l
Class: BE-IT
Semester: VII
Subject: Secure Application Development Lab

Experiment – 3: Study and implement at least any 5 methodologies of

OWASP
Aim: Study of OWASP Top 10 Security Risks or Vulnerabilities by OWASP

Course Objective: To understand the Owasp methodologies and standards

Course Outcome: Illustrate the Owasp methodologies and standards.

Theory:
What is OWASP Top 10?
The OWASP Top 10 is a standard document which consists of the top ten of the most impactful
web application security risks in the world. The Open Web Application Security Project
foundation (OWASP) publishes a version every three years. OWASP collects data from
companies which specialize in application security. It also collects data from individuals using
industry surveys. All of the results get ranked based on impact and prevalence. At last, the top
ten risks are then filtered. OWASP Top ten doesn’t cover all the vulnerabilities, but it’s a solid
start for security testers, developers and organizations who want to exploit vulnerabilities and
implement measures to protect against the security risks.

OWASP Top 10 vulnerabilities

This section provides you with the OWASP Top 10 summary of all the security risks. For each
one of them, there are links to dedicated posts which detail the theory and help you practice on
hands-on challenges. I recommend you bookmark this page and learn each vulnerability at a
time. Once you finish it to the end, you will have a solid understanding and will be ready to
test the OWASP Top 10 vulnerabilities on your own. You can even look for what you’ve
learned on bug bounty platforms and get paid!
Injection
An injection is a security risk that you can find on pretty much any target. Basically, it happens
when a server-side interpreter processes untrusted user input as part of a command or a query.
There are many vulnerabilities which cause injection. Here are some examples:
• SQL injection: You can find a SQL injection when the developer runs a SQL query
that takes a parameter you control as an input. If you successfully exploit it, you steal
data from the database, edit it or delete it altogether.
• OS command injection: It happens when user input is used as part of an insecure call
to operating system commands. If you find one, you can run arbitrary operating system
commands on the vulnerable server.
 • XPATH injection: It targets the query language typically used in XML. When you can
control part of the query. Therefore, you can bypass restrictions, read unauthorized
XML nodes, etc.
• Server-Side Template Injection: This flaw affects applications which use template
engines to render server-side data. If you can control variables passed into the template,
you can achieve remote code execution.
• LDAP Injection: When your target insecurely uses some user input to query an LDAP
directory, you can perform an injection to bypass restrictions, read unauthorized data,
etc.

• Broken authentication and session management

Authentication is a feature which verifies an identity’s claims. For example, when you login
into an application, it uses your username and password to verify that you are indeed who you
are claiming to be. Upon authentication, and due to the stateless nature of HTTP, the application
provides you with a session representing your identity, which your web browser sends on your
subsequent requests. Of course, you need to be able to sign up, log in, reset your password or
enable Multi-Factor authentication. That’s why authentication is hard to implement without
making any mistakes. Any flaw in one of those features can lead to broken authentication. We
cover this in detail in a dedicated blog post.
• Sensitive data exposure
If your IT assets disclose data which is not meant to be publicly accessible, they suffer from
sensitive data exposure. On the one hand, this data can be at rest, like your databases or files.
On the other hand, it can be in transit, especially if you are using unencrypted or weak
encryption for your data transmission. Apart from exposing your customers’ data which is a
scandal, you will also get fines for exposing them. Think of the GDPR regulation where fines
can go up to 20 million Euros.
• XML-External Entity (XXE)
XXE is a flaw in the way XML parsers get configured. Specifically, this vulnerability happens
when the XML parser can evaluate DTDs and external entities. It allows an attacker to achieve
many exploits, like listing directories and reading files from the server. It can even provoke a
Denial of Service.
• Broken access control
Broken access control happens when the application allows a user to perform unauthorized
actions. There are many vulnerabilities which contribute to this risk, For instance, if the
developer forgets to validate permissions when dealing with identifiers, the application
becomes vulnerable to Insecure Direct Object Reference (IDOR). Other vulnerabilities include
Cross-site Request Forgery (CSRF), Cross-Origin Resource Sharing (CORS)
misconfigurations and forced browsing. Read more about them in the dedicated blog post.
• Security misconfiguration
Security misconfigurations, as the name suggests, expose vulnerabilities due to weak
configurations of an IT asset. It doesn’t affect web assets only. Any component which requires
a configuration is subject to this vulnerability. This means that network devices, hardware,
email services, etc. can suffer from this vulnerability. For instance, your smart door lock can
have a predefined default administration PIN code. If you don’t change it, anyone can access
and change your device configuration. In the context of web applications, you can find things
like directory listing enabled, which would allow you to list all files and directories. Or maybe
the developer forgot to disable the debug mode, allowing you to get more insights on the inner-
workings of the vulnerable application.
• Cross-site Scripting (XSS)
This is one of the famous client-side vulnerabilities. It allows an attacker to run arbitrary
Javascript code on the victim’s web browser. XSS becomes possible when user input ends up
inside an HTML page or a piece of Javascript code without proper encoding. There are
basically three types of XSS, all of them along with hands-on tutorials are explained further:
1. Stored XSS happens when the user input gets stored in the application’s datastore, then
retrieved back and rendered in a page without proper encoding.
2. Reflected XSS happens when user input gets directly returned into the HTML page
without proper encoding.
3. DOM XSS happens when user input gets inside a Javascript code. Here, it is possible
to exploit XSS even if there is no request made to the server.

• Insecure deserialization
Insecure deserialization happens when the developer doesn’t check serialized data that a user
sends to the application. This is another vulnerability where a lack of user input validation can
lead to serious security problems. It is hard to exploit, but when it works, it can lead to either
remote code execution or denial of service.
• Using components with known vulnerabilities
You might have totally secured your own code, but what about the dependencies you are using?
Have you checked them or just imported them into your code? There is a high chance that one
or more of them are vulnerable. Unfortunately, using components with known vulnerabilities
had led to many serious breaches in the past, and will still cause many breaches to come. But
you already have the tools to check for them. For more in-depth knowledge of that, head to this
dedicated article.
• Insufficient logging and monitoring
When a hacker infiltrates a network, IT systems will generate traffic which usually doesn’t
correspond to the normal one, unless you are dealing with highly skilled hackers who have
time and money to go after your IT infrastructure. If you can’t detect this abnormal behavior
as soon as possible, you are essentially giving them enough time to achieve their goal. Read
more about this in this blog post. Logging and monitoring should be part of your essential
security infrastructure because you simply cannot defend what you don’t know.
OWASP Top 10 vulnerabilities 2021:
• A01:2021-Broken Access Control moves up from the fifth position to the category with
the most serious web application security risk; the contributed data indicates that on
average, 3.81% of applications tested had one or more Common Weakness
Enumerations (CWEs) with more than 318k occurrences of CWEs in this risk category.
The 34 CWEs mapped to Broken Access Control had more occurrences in applications
than any other category.
• A02:2021-Cryptographic Failures shifts up one position to #2, previously known as
A3:2017-Sensitive Data Exposure, which was broad symptom rather than a root cause.
The renewed name focuses on failures related to cryptography as it has been implicitly
before. This category often leads to sensitive data exposure or system compromise.
• A03:2021-Injection slides down to the third position. 94% of the applications were
tested for some form of injection with a max incidence rate of 19%, an average
incidence rate of 3.37%, and the 33 CWEs mapped into this category have the second
most occurrences in applications with 274k occurrences. Cross-site Scripting is now
part of this category in this edition.
• A04:2021-Insecure Design is a new category for 2021, with a focus on risks related to
design flaws. If we genuinely want to "move left" as an industry, we need more threat
modelling, secure design patterns and principles, and reference architectures. An
insecure design cannot be fixed by a perfect implementation as by definition, needed
security controls were never created to defend against specific attacks.
• A05:2021-Security Misconfiguration moves up from in the previous edition; 90% of
applications were tested for some form of misconfiguration, with an average incidence
rate of 4.5%, and over 208k occurrences of CWEs mapped to this risk category. With
more shifts into highly configurable software, it's not surprising to see this category
move up. The former category for A4:2017-XML External Entities (XXE) is now part
of this risk category.
• A06:2021-Vulnerable and Outdated Components was previously titled Using
Components with Known Vulnerabilities and is in the Top 10 community survey, but
also had enough data to make the Top 10 via data analysis. This category moves up
from in 2017 and is a known issue that we struggle to test and assess risk. It is the only
category not to have any Common Vulnerability and Exposures (CVEs) mapped to the
included CWEs, so a default exploit and impact weights of 5.0 are factored into their
scores.
• A07:2021-Identification and Authentication Failures was previously Broken
Authentication and is sliding down from the second position, and now includes CWEs
that are more related to identification failures. This category is still an integral part of
 the Top 10, but the increased availability of standardized frameworks seems to be
helping.
• A08:2021-Software and Data Integrity Failures is a new category for 2021, focusing
on making assumptions related to software updates, critical data, and CI/CD pipelines
without verifying integrity. One of the highest weighted impacts from Common
Vulnerability and Exposures/Common Vulnerability Scoring System (CVE/CVSS)
data mapped to the 10 CWEs in this category. A8:2017-Insecure Deserialization is now
a part of this larger category.
• A09:2021-Security Logging and Monitoring Failures was previously A10:2017-
Insufficient Logging & Monitoring and is added from the Top 10 community survey,
moving up from previously. This category is expanded to include more types of failures,
is challenging to test for, and isn't well represented in the CVE/CVSS data. However,
failures in this category can directly impact visibility, incident alerting, and forensics.
• A10:2021-Server-Side Request Forgery is added from the Top 10 community survey.
The data shows a relatively low incidence rate with above average testing coverage,
along with above-average ratings for Exploit and Impact potential. This category
represents the scenario where the security community members are telling us this is
important, even though it's not illustrated in the data at this time.

Conclusion: OWASP Top 10 Web App Vulnerabilities represents a broad consensus among
security experts of the most common security risks facing organizations. The vision behind
OWASP Top 10 Application Security Risks is to build a culture of secure web development
and web application security through awareness creation
Class: BE-IT
Semester: VII
Subject: Secure Application Development Lab

Experiment – 4: Demonstrate of OS Command injection vulnerability using

DVWA.
Aim: Demonstrate of OS Command injection vulnerability using DVWA.
Course Objective: Understand and Identify main vulnerabilities inherent in applications.
Course Outcome: Identify main vulnerabilities inherent in application.

Theory:
Damn Vulnerable Web App (DVWA) is a PHP/MySQL web application that is damn
vulnerable. Its main goals are to be an aid for security professionals to test their skills and tools
in a legal environment, help web developers better understand the processes of securing web
applications and aid teachers/students to teach/learn web application security in a classroom
environment. The aim of DVWA is to practice some of the most common web vulnerabilities,
with various levels of difficulty, with a simple straightforward interface.

OS command injection vulnerability

Command injection is an attack in which the goal is execution of arbitrary commands on the
host operating system via a vulnerable application. Command injection attacks are possible
when an application passes unsafe user supplied data (forms, cookies, HTTP headers etc.) to a
system shell. In this attack, the attacker-supplied operating system commands are usually
executed with the privileges of the vulnerable application. Command injection attacks are
possible largely due to insufficient input validation.

Steps to install DVWA:

1. Download and install XAMPP on your computer.
2. Download DVWA from GitHub
3. Open XAMPP and start ‘Apache and MySQL’
4. Extract DVWA downloaded file in htdocs that will be available in C:\xampp
5. Open htdocs folder and rename ‘DVWA-master’ to ‘dvwa’
6. A filename ‘config.inc.php.dist ‘ rename it to ‘config.inc.php’ it will be available in
C:\xampp\htdocs\dvwa\config
7. type ‘127.0.0.1/dvwa’ in the URL of the browser if you get error connecting to dvwa
goto
8. Open with notepad config.inc.php in C:\xampp\htdocs\dvwa\config and change
db_user to root and db_password to blank as shown in figure below.
 9. Now, again type ‘127.0.0.1/dvwa’ in the URL of the browser,
10. click on ‘Create / Reset Database’
11. Click on ‘Login’ or it will automatically redirect to the login page,
12. The default username is ‘admin’ and the password is ‘password’ login with the
credentials.
13. Perform os command injection on dvwa.

Conclusion. Successfully installed Xampp , dvwa and performed command injection with all
security levels low,high medium
Class: BE-IT
Semester: VII
Subject: Secure Application Development Lab

Experiment – 5: To study and implement at least any 5 OAT Denial of Inventory

Aim: To study and implement at least any 5 OAT Denial of Inventory.

Lab objective: Understand the OWASP methodologies and standards.

Theory:
➢ OAT - 021: Denial of Inventory – Deplete goods or services stock without ever completing
the purchase or committing to the transaction. Selection and holding of items from a limited
inventory or stock, but which are never actually bought, or paid for, or confirmed such that
other users are unable to buy/pay/confirm the items themselves.
Denial of Inventory is most commonly thought of as taking Ecommerce items out of circulation
by adding many of them to a cart/basket, the attacker never actually proceeds to checkout to
buy them but contributes to a possible stock-out condition. A variation of this automated threat
event is making reservations (e.g., hotel rooms, restaurant tables, holiday bookings, flight
seats), and/or click-and-collect without payment. But this exhaustion of inventory availability
also occurs in other types of web application such as in the assignment of non-goods like
service allocations, product rations, availability slots, queue positions, and budget
apportionments.

➢ OAT – 005: Scalping - Acquisition of goods or services using the application in a manner that
a normal user would be unable to undertake manually. Although Scalping may include
monitoring awaiting availability of the goods or services, and then rapid action to beat normal
users to obtain these, Scalping is not a “last minute” action like OAT-013 Sniping, nor just
related to automation on behalf of the user such as in OAT-006 Expediting. This is because
Scalping includes the additional concept of limited availability of sought-after goods or
services, and is most well known in the ticketing business where the tickets acquired are then
resold later at a profit by the scalpers/touts. This can also lead to a type of user denial of service,
since the goods or services become unavailable rapidly.

➢ OAT – 013: Snipping - Last-minute bid or offer for goods or services. The defining
characteristic of sniping is an action undertaken at the latest opportunity to achieve a particular
objective, leaving insufficient time for another user to bid/offer. Sniping can also be the
automated exploitation of system latencies in the form of timing attacks. Careful timing and
 prompt action are necessary parts. It is most well known as auction sniping, but the same threat
event can be used in other types of applications. Sniping normally leads to some dis-benefit
for other users, and sometimes that might be considered a form of denial of service. Sniping is
also known by the terms such as auction sniping, bid sniper, frontrunning, last look, last minute
bet and timing attack.

➢ OAT – 006: Expediting - Perform actions to hasten the progress of usually slow, tedious or
time-consuming operations. Using speed to violate explicit or implicit assumptions about the
application’s normal use to achieve unfair individual gain, often associated with deceit and
loss to some other party. In contrast to OAT-016 Skewing which affects metrics, Expediting
is purely related to faster progression through a series of application processes. OAT-017
Spamming is different to Expediting, since the focus of spam is to add information, and may
not involve the concept of process progression. Expediting is also known by the terms such as
algorithmic trading, automated stock trading, betting automation, game automation, gaming
bot, gold farming, financial instrument dealing, high-frequency trading, last look trade, mining,
purchase automation, trading automation, ticketing automation, virtual wealth generation bot.

➢ OAT – 016: Skewing - Repeated link clicks, page requests or form submissions intended to
alter some metric. It is an automated repeated clicking or requesting or submitting content,
affecting application-based metrics such as counts and measures of frequency and/or rate. The
metric or measurement may be visible to users (e.g., betting odds, likes, market/dynamic
pricing, visitor count, poll results, and reviews) or hidden (e.g., application usage statistics,
business performance indicators). Metrics may affect individuals as well as the application
owner, e.g., user reputation, influence others, gain fame, or undermine someone else's
reputation. Skewing is also known by the terms such as biasing KPIs, hit count fraud, metric
and statistic skewing, page impression fraud, poll fraud, poll skewing and rating/review
skewing.

➢ OAT – 017: Spamming - Malicious or questionable information addition that appears in

public or private content, databases or user messages. Malicious content can include malware,
IFRAME distribution, photographs and videos, advertisements, referrer spam and
tracking/surveillance code. The content might be less overtly malicious but be an attempt to
cause mischief, undertake search engine optimization (SEO) or to dilute/hide other posts. The
mass abuse of broken form-to-email and form-to-SMS functions to send messages to
unintended recipients is not included in this threat event, or any other in this ontology, since
those are considered to be the exploitation of implementation flaws alone. Spamming is also
known by the terms such as blog spam, bulletin board spam, clickbait, comment spam, content
spam, content spoofing, fake news, form spam, forum spam, guestbook spam, referrer spam,
review spam, spambot and SEO spam.
CODE/OUTPUT:
1. baidu.com

2. example.com
3. comodoca.com
4. gzip.org
 5. webgarden.com

LAB OUTCOME: L02: Understand the OWASP methodologies and standards.

CONCLUSION: Hence, we have successfully implemented at least any 5 OAT Denial of
Inventory.
Class: BE-IT
Semester: VII
Subject: Secure Application Development Lab

Experiment – 6: Use of Burp proxy to test web applications.

Aim: Use of Burp proxy to test web applications.

Lab objective: Understand and identify main vulnerabilities inherent in applications.

Theory :
What is the use of Burp Suite? Burp Suite is an integrated platform/graphical tool for performing
security testing of web applications. Its various tools work seamlessly together to support the entire
testing process, from initial mapping and analysis of an application's attack surface, through to
finding and exploiting security vulnerabilities. Burp Suite is installed by default in Kali Linux.
The tool is written in Java and developed by PortSwigger Web Security. The tool has three
editions: a Community Edition that can be downloaded free of charge, a Professional Edition and
an Enterprise Edition that can be purchased after a trial period. The Community edition has
significantly reduced functionality. It intends to provide a comprehensive solution for web
application security checks. In addition to basic functionality, such as proxy server, scanner and
intruder, the tool also contains more advanced options such as a spider, a repeater, a decoder, a
comparer, an extender and a sequencer.
Burp Suite can be classified as an Interception Proxy. While browsing their target application, a
penetration tester can configure their internet browser to route traffic through the Burp Suite proxy
server. Burp Suite then acts as a (sort of) Man In The Middle by capturing and analyzing each
request to and from the target web application so that they can be analyzed. Penetration testers can
pause, manipulate and replay individual HTTP requests in order to analyze potential parameters
or injection points. Injection points can be specified for manual as well as automated fuzzing
attacks to discover potentially unintended application behaviors, crashes and error messages.

Steps for using Burp Proxy:

1. For Unsecured Website
Step 1: Setup Project details and proceed
Step 2: Go to options in proxy and take note of IP address and port

Step 3: Open Firefox settings, search for “Network Settings” and then select Manual proxy
option. Then Enter the IP address and port for http, https and socket:
Step 4: Go to burp proxy and turn on Intercept by clicking the button

Step 5: Now open an unsecured website in browser (firefox), you will see that the packets are
going through the burp proxy and you have the options to forward or drop the packet.
Step 6: Dropping the packets will halt the loading of website:

Step 7: Forwarding the packets will let the website load.

Step 8: You can also modify the content of the packet and then forward it. Forward the packets
until you reach your desired packet, then click on Action > Do Intercept > Response to this Request
and then forward the Packet.

Step 9: Now you will be able to edit the content of the response body and then forward it.
2. For Secured Website
Step 1: To use burp proxy with a secured website you have to setup certificate. Download the
certificate by going to http://burp while the burp proxy is on and click on CA Certificate.
Step 2: Go to Firefox settings and search for Certificates. Click on import certificate and import
the certificate, downloaded in the previous step.

Step 3: Now you can intercept the Secured website as well in burp proxy
Outcome: L03: Identify main vulnerabilities inherent in applications.
Conclusion: Hence, we have successfully used burp proxy suite in intercepting the secured and
unsecured website.
Class: BE-IT
Semester: VII
Subject: Secure Application Development Lab

Experiment – 7: To apply registration Page Data Validation.

Aim: To apply registration Page Data Validation.

Lab objective: Understand how Data Validation and Authentication can be applied for
application.

Theory:
Forms are used in webpages for the user to enter their required details that further send it to the
server for processing. A form is also known as a web form or HTML form. Examples of form
use are prevalent in e-commerce websites, online banking, online surveys to name a few.
Validating a form: The data entered into a form needs to be in the right format and certain fields
need to be filled in order to effectively use the submitted form. Username, password, contact
information are some details that are mandatory in forms and thus need to be provided by the
user.
Userid - This attribute above checks whether userid input field is provided with a string of length
5 to 12 characters. If not, it displays an alert.
Password - This attribute code used to validate password (it should be of length 7 to 12 characters).
If not, it displays an alert.
user name - This attribute checks whether user name input field is provided with alphabets
characters. If not, it displays an alert.
user address - It checks whether user address input field is provided with alphanumeric characters.
If not, it displays an alert.
Country - The code above checks whether a country is selected from the given list. If not, then it
displays an alert.
ZIP code - The attribute checks whether a ZIP code of numeric value. If not, it displays an alert.
email format - The code above checks whether a valid email format is supplied. If not, it displays
an alert.
Gender - The code above checks whether a sex is selected. If not, it displays an alert. If Male or
Female is selected, it generates an alert saying that the form is successfully submitted and it reloads
the form.
CODE:

sad7.html
<!DOCTYPE html>

<html lang="en">

<head>

<meta charset="UTF-8">

<meta http-equiv="X-UA-Compatible" content="IE=edge">

<meta name="viewport" content="width=device-width, initial-scale=1.0">

<link rel="stylesheet" href="sad7.css" />

<title>Document</title>

</head>

<body onload="document.registration.userid.focus();">

<h1>Registration Form</h1>

<form name='registration' onSubmit="return formValidation();">

<ul>

<li><label for="userid">User id:</label></li>

<li><input type="text" name="userid" size="12" /></li>

<li><label for="passid">Password:</label></li>

<li><input type="password" name="passid" size="12" /></li>

<li><label for="username">Name:</label></li>

<li><input type="text" name="username" size="50" /></li>

<li><label for="address">Address:</label></li>
 <li><input type="text" name="address" size="50" /></li>

<li><label for="country">Country:</label></li>

<li><select name="country">

<option selected="" value="Default">(Please select a country)</option>

<option value="AF">Australia</option>

<option value="AL">Canada</option>

<option value="DZ">India</option>

<option value="AS">Russia</option>

<option value="AD">USA</option>

</select></li>

<li><label for="zip">ZIP Code:</label></li>

<li><input type="text" name="zip" /></li>

<li><label for="email">Email:</label></li>

<li><input type="text" name="email" size="50" /></li>

<li><label id="gender">Sex:</label></li>

<li><input type="radio" name="msex" value="Male" /><span>Male</span></li>

<li><input type="radio" name="fsex" value="Female" /><span>Female</span></li>

<li><label>Language:</label></li>

<li><input type="checkbox" name="en" value="en" checked /><span>English</span></li>

<li><input type="checkbox" name="nonen" value="noen" /><span>Non English</span></li>

<li><label for="desc">About:</label></li>

<li><textarea name="desc" id="desc"></textarea></li>

<li><input type="submit" name="submit" value="Submit" /></li>

</ul>

</form>

</body>

<script src="sad7.js"></script>
</html>

sad7.js

function formValidation() {

var uid = document.registration.userid;

var passid = document.registration.passid;

var uname = document.registration.username;

var uadd = document.registration.address;

var ucountry = document.registration.country;

var uzip = document.registration.zip;

var uemail = document.registration.email;

var umsex = document.registration.msex;

var ufsex = document.registration.fsex;

if (userid_validation(uid, 5, 12)) {

if (passid_validation(passid, 7, 12)) {

if (allLetter(uname)) {

if (alphanumeric(uadd)) {

if (countryselect(ucountry)) {

if (allnumeric(uzip)) {

if (ValidateEmail(uemail)) {

if (validsex(umsex, ufsex)) {

}
 }

return false;

} function userid_validation(uid, mx, my) {

var uid_len = uid.value.length;

if (uid_len == 0 || uid_len >= my || uid_len < mx) {

alert("User Id should not be empty / length be between " + mx + " to " + my);

uid.focus();

return false;

return true;

function passid_validation(passid, mx, my) {

var passid_len = passid.value.length;

if (passid_len == 0 || passid_len >= my || passid_len < mx) {

alert("Password should not be empty / length be between " + mx + " to " + my);

passid.focus();

return false;

return true;

function allLetter(uname) {

var letters = /^[A-Za-z]+$/;

if (uname.value.match(letters)) {

return true;

}
 else {

alert('Username must have alphabet characters only');

uname.focus();

return false;

function alphanumeric(uadd) {

var letters = /^[0-9a-zA-Z]+$/;

if (uadd.value.match(letters)) {

return true;

else {

alert('User address must have alphanumeric characters only');

uadd.focus();

return false;

function countryselect(ucountry) {

if (ucountry.value == "Default") {

alert('Select your country from the list');

ucountry.focus();

return false;

else {

return true;

}
function allnumeric(uzip) {

var numbers = /^[0-9]+$/;

if (uzip.value.match(numbers)) {

return true;

else {

alert('ZIP code must have numeric characters only');

uzip.focus();

return false;

function ValidateEmail(uemail) {

var mailformat = /^\w+([\.-]?\w+)@\w+([\.-]?\w+)(\.\w{2,3})+$/;

if (uemail.value.match(mailformat)) {

return true;

else {

alert("You have entered an invalid email address!");

uemail.focus();

return false;

} function validsex(umsex, ufsex) {

x = 0;

if (umsex.checked) {

x++;

} if (ufsex.checked) {
 x++;

if (x == 0) {

alert('Select Male/Female');

umsex.focus();

return false;

else {

alert('Form Succesfully Submitted');

window.location.reload()

return true;

}
OUTPUT:
Lab outcome: LO4: Apply Data Validation and Authentication for application.

Conclusion: Hence, we have successfully applied registration Page Data Validation.

Class: BE-IT
Semester: VII
Subject: Secure Application Development Lab

Experiment – 8: Cross-Site Scripting (XSS) vulnerability Lab

Aim:

a) To apply SQL injection vulnerability that allows login page to Bypass.

b) Cross-Site Scripting (XSS) vulnerability Lab

Lab objective:
Understand how Data Validation and Authentication can be applied for application

Theory:
a) SQL Injection
SQL injection (SQLi) is a web security vulnerability that allows an attacker to interfere with the
queries that an application makes to its database. It generally allows an attacker to view data that
they are not normally able to retrieve. This might include data belonging to other users, or any
other data that the application itself is able to access. In many cases, an attacker can modify or
delete this data, causing persistent changes to the application's content or behaviour.

In some situations, an attacker can escalate an SQL injection attack to compromise the underlying
server or other back-end infrastructure, or perform a denial-of-service attack.

There are a wide variety of SQL injection vulnerabilities, attacks, and techniques, which arise in
different situations. Some common SQL injection examples include:

• Retrieving hidden data, where you can modify an SQL query to return additional results.
• Subverting application logic, where you can change a query to interfere with the
application's logic.
• UNION attacks, where you can retrieve data from different database tables. Examining
the database, where you can extract information about the version and structure of the
database.
• Blind SQL injection, where the results of a query you control are not returned in the
application's responses.
b) Cross-Site Scripting (XSS)
Cross-site scripting (also known as XSS) is a web security vulnerability that allows an
attacker to compromise the interactions that users have with a vulnerable application. It allows
an attacker to circumvent the same origin policy, which is designed to segregate different websites
from each other. Cross-site scripting vulnerabilities normally allow an attacker to masquerade
as a victim user, to carry out any actions that the user is able to perform, and to access any of
the user's data. If the victim user has privileged access within the application, then the attacker
might be able to gain full control over all of the application's functionality and data.

There are three main types of XSS attacks. These are:

1. Reflected XSS, where the malicious script comes from the current HTTP request.
2. Stored XSS, where the malicious script comes from the website's database.
3. DOM-based XSS, where the vulnerability exists in client-side code rather than server-side
code.

Implementation:

a) SQL Injection
In this website, we entered a smartly formatted input in the password field which was
105' OR '1'='1
Which made the internal sql query to be:
b) SELECT * FROM users WHERE username = '105' AND

Code/output:
 OR '
b) Cross-site scripting (XSS)

In this website, I entered a script tag with a custom JavaScript code in the search query of the
page, and as the text in the query was placed in the result page, the script got executed and the
alert was shown with a custom message that I mentioned in the code.
Lab outcome: L04: Apply Data Validation and Authentication for application.

Conclusion: Hence, we have successfully applied SQL injection and Cross Scripting.
Class: BE-IT
Semester: VII
Subject: Secure Application Development Lab

Experiment – 9: To study and implement session Management for Web

Application.
Aim: To study and implement session Management for Web Application.

Lab objective: Understand how to apply Security at Session Layer Management.

Theory:
HTTP is a “stateless” protocol. Which means there is no “built-in” standard to keep track of
interrelated requests. Each request is treated as independent. Currently, most of the web
applications are using HTTP 1.1 which was released in 1996. These web applications are very
advanced and usually handle complex operations which take more than one pair of
request/response to complete, this requires something to track the present state of operation. These
apps also present tailored content to each user. This requires identifying a user across multiple
requests. So there must be something that adds an “enhancement” to HTTP.
There are solutions that are the results of clever thinking by web programmers.
HTTP uses client-server architecture and uses TCP as its transmission protocol and multiple
requests can be sent over just one TCP connection, but these are also considered independent by
both client and server. There are two aspects of session in HTTP as discussed above. There are
mainly two ways to achieve tracking across requests.
• Request Parameters:
The token that represents the current state of a multistep process or identifies a user can be
stored by the server on the web page in a form field, which will be auto-submitted each time
user performs an action. The token is contained as a value of an input field. This token can be
submitted as either a GET request parameter or a POST request parameter. The request
parameters in a GET request are embedded in the URL and these are recorded in the browser
history. While POST submits the parameters as request body so it doesn’t get embedded in
URL and doesn’t show up in browser history either. Obviously, for submitting sensitive
information POST requests should be used, while GET requests can be used for information
that is sensitive. For example, if the token is an identifier for a user it must always be sent in
POST request. Non-sensitive examples of tokens include state identifiers, referrer values etc.
There is another way of sending identifiers in GET requests. Which uses path name instead
of parameters.
• Cookies
Cookies are name-value pairs that are stored on the browser and submitted automatically in
subsequent requests. The server generates them and sends them to the client by using “set-cookie”
HTTP header. A cookie is submitted using “cookie” header. The cookie header sends name-value
pairs separated by semicolons. The set-cookie header contains extra directives and parameters for
cookies. These help browser in understanding how and when to submit them.
The most common parameters are- domain, path and expires while the directives are – “secure”
and “httponly”. The domain parameter specifies the domain for which cookie is valid, the cookie
will also be valid for all its subdomains. The path parameter specifies the URL path. Expires is
self-explanatory.
The “secure” directive instruct browser to send the cookie over HTTPS only while “httponly”
instructs browser to not let the website JavaScript to access the cookie. This is done to prevent
exploitation of XSS that steals cookies, in case the website is vulnerable to XSS.
Code:
const http = require('http')

const port = process.env.PORT || 3000

const server = http.createServer((req, res) => {

console.log(req.url);
res.statusCode = 200
res.setHeader('Content-Type', 'text/html')
if (req.url == '/') {
res.end('<h1> This is Srushti </h1>')
}
else if (req.url == '/about') {
res.statusCode = 200
res.end('<h2> About Srushti </h2>')
}
 else {
res.statusCode = 404
res.end('<h1> Error </h1>')
}
})
server.listen(port, () => {
console.log(`Server is listening on port ${port}`);
})

Output:
Lab outcome: LO5: Apply Security at Session Layer Management.
Conclusion: Hence, we have successfully implemented Session Management for Web
Applications.
Class: BE-IT
Semester: VII
Subject: Secure Application Development Lab

Experiment – 10: To study types of cryptography Symmetric and Asymmetric

Aim: To study types of cryptography Symmetric and Asymmetric.

Lab objective: Understand how to apply to secure coding for cryptography.

Theory:
CRYPTOGRAPHY: Cryptography is a method of protecting information and communications
through the use of codes, so that only those for whom the information is intended can read and
process it.
In computer science, cryptography refers to secure information and communication techniques
derived from mathematical concepts and a set of rule-based calculations called algorithms, to
transform messages in ways that are hard to decipher.

Symmetric Cryptography: Symmetric cryptography, known also as secret key cryptography, is

the use of a single shared secret to share encrypted data between parties. Ciphers in this category
are called symmetric because you use the same key to encrypt and to decrypt the data. In simple
terms, the sender encrypts data using a password, and the recipient must know that password to
access the data.
Symmetric encryption is a two-way process. With a block of plaintext and a given key, symmetric
ciphers will always produce the same ciphertext. Likewise, using that same key on that block of
ciphertext will always produce the original plaintext. Symmetric encryption is useful for protecting
data between parties with an established shared key and is also frequently used to store confidential
data. For example, ASP.NET uses 3DES to encrypt cookie data for a forms authentication ticket.
Types of Symmetric Cryptography:
• DES - Data encryption standard (DES) has been found vulnerable to very powerful
attacks and therefore, the popularity of DES has been found slightly on the decline. DES
is a block cipher and encrypts data in blocks of size of 64 bits each, which means 64 bits
of plain text go as the input to DES, which produces 64 bits of ciphertext. The same
algorithm and key are used for encryption and decryption, with minor differences. The
key length is 56 bits.
• 3DES - Although it’s officially known as the Triple Data Encryption Algorithm (3DEA),
it is most commonly referred to as 3DES. This is because the 3DES algorithm uses the
Data Encryption Standard (DES) cipher three times to encrypt its data.
DES is a symmetric-key algorithm based on a Feistel network. As a symmetric key
cipher, it uses the same key for both the encryption and decryption processes. The Feistel
network makes both of these processes almost exactly the same, which results in an
algorithm that is more efficient to implement.
DES has both a 64-bit block and key size, but in practice, the key only grants 56-bits of
security. 3DES was developed as a more secure alternative because of DES’s small key
length. In 3DES, the DES algorithm is run through three times with three keys; however,
it is only considered secure if three separate keys are used.

• AES - Advanced Encryption Standard (AES) is a specification for the encryption of

electronic data established by the U.S National Institute of Standards and Technology
(NIST) in 2001. AES is widely used today as it is a much stronger than DES and triple
DES despite being harder to implement.
Points to remember
❖ AES is a block cipher.
❖ The key size can be 128/192/256 bits.
❖ Encrypts data in blocks of 128 bits each.
That means it takes 128 bits as input and outputs 128 bits of encrypted cipher text as
output. AES relies on substitution-permutation network principle which means it is
 performed using a series of linked operations which involves replacing and shuffling of
the input data.

Asymmetric Cryptography: Asymmetric cryptography is a second form of

cryptography. Asymmetric cryptography is scalable for use in very large and ever expanding
environments where data are frequently exchanged between different communication partners.
Asymmetric cryptography is often used to exchange the secret key to prepare for
using symmetric cryptography to encrypt data. In the case of a key exchange, one party creates
the secret key and encrypts it with the public key of the recipient. The recipient would then
decrypt it with their private key. The remaining communication would be done with the secret
key being the encryption key. Asymmetric encryption is used in key exchange, email security,
Web security, and other encryption systems that require key exchange over the public network.
Types of Asymmetric Cryptography:
• RSA - The idea of RSA is based on the fact that it is difficult to factorize a large integer.
The public key consists of two numbers where one number is multiplication of two large
prime numbers. And private key is also derived from the same two prime numbers. So if
somebody can factorize the large number, the private key is compromised. Therefore
encryption strength totally lies on the key size and if we double or triple the key size, the
strength of encryption increases exponentially. RSA keys can be typically 1024 or 2048
bits long, but experts believe that 1024bit keys could be broken in the near future. But till
now it seems to be an infeasible task.
 • DSA - DSA (Digital Signature Algorithm) incorporates the algebraic properties of
discrete logarithm problems and modular exponentiations for generating an electronic
signature for various applications. Most digital signature creation algorithms follow the
typical technique of signing the message digest (hash of the actual message) with the
source private key to create the digital thumbprint.
However, the situation is different in DSA as it generates two signatures by incorporating
two complex and unique signing and verification functions. Hence, the DSA algorithm is
not a simple use of private and public keys at the start and end of the communication.
The DSA algorithm works on the systematic computation mechanism that computes a
hash value and a digital signature constituting two 160-bit numbers from the message
digest and the private key. The randomness makes the signature non-deterministic. It uses
a public key for signature authentication, which is way more complex than RSA.

Lab outcome: LO6: Apply secure coding for cryptography.

Conclusion: Hence, we have successfully studied types of cryptography Symmetric and
Asymmetric.