What is Web Application?

Web applications, also called web apps, are programs that allow users to perform actions online.
Many businesses use these programs to communicate with customers, sell products and improve work
processes. Understanding what a web application is can help you deepen your understanding of the role
technology plays in the workplace.

In this article, we define web applications, list some common functions for these programs,
explain how they work, list some key benefits of using them and share some examples of jobs that
require them.

A web application is a computer program that uses a web browser to perform a particular
function. They are client-server programs, so each program has a client side and a server side. In the
client-server environment, a client is a program an individual uses to run the application, while a server
processes the data needed to run the application for the user. For example, with a database, the client is
the program through which the user enters data and the server is the application that stores the
information.

Websites often host web applications, which allow visitors to perform certain actions when they
visit the site. For example, the website for a shoe company might host an online store application, which
allows shoppers to add products to their carts and submit payments. The company's web administrator
might choose which web applications to add to the site and customize the apps to meet their customers'
needs. A website might host multiple applications, like chat modules, payment pages and interactive
product customization tools.

A web application is a kind of computer programme. It uses online technology (including

browsers) to perform a huge range of different tasks.

https://www.indeed.com/career-advice/career-development/what-is-web-application
https://www.ringcentral.com/gb/en/blog/definitions/web-application/

What are Vulnerabilities?

the quality of being vulnerable (= able to be easily hurt, influenced, or attacked)

A vulnerability is a weakness or error in a system or device’s code that, when exploited, can
compromise the confidentiality, availability, and integrity of data stored in them through unauthorized
access, elevation of privileges, or denial of service. A code or tool used to take advantage of a
vulnerability is called an exploit.

https://www.upguard.com/blog/vulnerability

https://www.trendmicro.com/vinfo/us/security/definition/Vulnerability
What Are Web Application Vulnerabilities?
https://www.contrastsecurity.com/glossary/application-vulnerability

https://www.acunetix.com/websitesecurity/web-application-attack/

A web application vulnerability is any system flaw that an attacker can exploit to compromise a
web application. Web application vulnerabilities involve a system flaw or weakness in a web-based
application. They have been around for years, largely due to not validating or sanitizing form inputs,
misconfigured web servers, and application design flaws, and they can be exploited to compromise the
application's security.

Application vulnerabilities are weaknesses in an application that an attacker could exploit to

harm the security of the application. Vulnerabilities can be introduced into an application in various
ways, such as failures in the design, implementation, or configuration of an application.

https://www.checkpoint.com/cyber-hub/cloud-security/what-is-an-application-vulnerability/

Why are web applications so vulnerable to attacks?

Security setting misconfigurations are one of the biggest drivers behind that stat. Web
applications can be attacked because their creators make errors that allow unauthorized people to
access sensitive data or gain administrative access rights to the web application itself or even to the
server.

Web applications are very vulnerable to attacks because they are not designed to be protected
by firewalls.They must be available to everyone, all the time, unless they are on an intranet. Malicious
hackers can, therefore, try to exploit them easily.

How can web apps be attacked?

https://www.indusface.com/blog/what-is-a-website-vulnerability-and-how-can-it-be-exploited/

Web app vulnerabilities are exploitable when there are no proper security measures in place to
prevent attackers from finding and taking advantage of vulnerabilities. The factors that affect the
exploitability of a vulnerability are the complexity associated with exploitation and the availability of
active/ known exploits.

Based on this, the risk associated with the vulnerability is calculated and vulnerabilities are
categorized into critical, high, medium, and low risk. The critical and high-risk vulnerabilities must be
fixed and protected on a high-priority basis.

Some facts and figures from 2020…

  75% of attacks leveraged web application vulnerabilities that were known at least for 2 years!

 80% of exploits were published even before the CVE (Common Vulnerabilities and Exposure)
related to that exploit was made public. This means, instead of organizations steering ahead of
attackers, attackers had the first-mover advantage in most exploits.

https://www.acunetix.com/blog/web-security-zone/secure-coding-practices/

https://www.comparitech.com/blog/information-security/cybersecurity-vulnerability-statistics/

8 COMMON TYPES OF WEB APPLICATION VULNERABILITIES

1. SQL Injection
SQL injection is a code injection technique that might destroy your database. Many applications use
Structured Query Language (SQL) to manage communications with the database. SQL vulnerabilities
allow attackers to insert malicious SQL commands to exfiltrate, modify, or delete data. Some hackers
use SQL to gain root access to the target system.

SQL injection attacks target servers that hold critical data used by web applications or services. They are
particularly dangerous when they expose critical or sensitive data, such as user credentials and personal
information. The most common vulnerability enabling SQL injection attacks is using unsanitized user
inputs. It is important to strip out any element in user-supplied inputs that the server could execute as
SQL code

Impact of SQL injection on your applications:

 Steal credentials—attackers can obtain credentials via SQLi and then

impersonate users and use their privileges.
 Access databases—attackers can gain access to the sensitive data in
database servers.
 Alter data—attackers can alter or add new data to the accessed database.
 Delete data—attackers can delete database records or drop entire tables.
 Lateral movement—attackers can access database servers with operating
system privileges, and use these permissions to access other sensitive
systems.
 Breaches Enabled by SQL Injection
 GhostShell attack—hackers from APT group Team GhostShell targeted 53
universities using SQL injection, stole and published 36,000 personal records
belonging to students, faculty, and staff.
 Turkish government—another APT group, RedHack collective, used SQL
injection to breach the Turkish government website and erase debt to
government agencies.
 7-Eleven breach—a team of attackers used SQL injection to penetrate corporate
systems at several companies, primarily the 7-Eleven retail chain, stealing 130
million credit card numbers.
 HBGary breach—hackers related to the Anonymous activist group used SQL
Injection to take down the IT security company’s website. The attack was a
response to HBGary CEO publicizing that he had names of Anonymous
organization members.

2. Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into
otherwise benign and trusted websites. XSS attacks are similar to SQL injection attacks and involve the
injection of malicious scripts into websites or web applications. The point of difference is that the
malicious code runs in the browser only when the user visits a compromised website or app. Attackers
often carry out XSS attacks by injecting code into input fields that the target page runs when visitors
view the page (e.g., embedded JavaScript link).

An XSS attack can expose user data without indicating a compromise, impacting business reputation in
the long run. Attackers can steal any sensitive data sent to the infected app, and the users may remain
oblivious.

What is the Impact of Cross-Site Scripting Vulnerability?

The impact of cross-site scripting vulnerabilities can vary from one web application to another. It
ranges from session hijacking to credential theft and other security vulnerabilities. By exploiting a cross-site
scripting vulnerability, an attacker can impersonate a legitimate user and take over their account.
If the victim user has administrative privileges, it might lead to severe damage such as modifications in code
or databases to further weaken the security of the web application, depending on the rights of the account
and the web application.

Here are some of the most common impacts of cross-site scripting attacks:

Account Hijacking
Attackers often steal session cookies in the browser to hijack legitimate user accounts. This allows attackers
to take over the victim's session and access any functionality or sensitive information on their behalf.
Assuming a malicious actor managed to steal the session cookies of an administrative account, the attacker
can gain administrative access to the entire web application.

Credential Theft
One of the most common XSS attack vectors is to use HTML and JavaScript in order to steal user credentials.
Attackers can clone the login page of the web application and then use cross-site scripting vulnerabilities to
serve it to the victims.
When a victim uses the vulnerable web page and inputs their credentials, they are forwarded to a server
under the attacker’s control. This way, attackers can obtain the credentials of a user in plaintext instead of
hacking their session cookies, which may expire.

Data Leakage
Another powerful XSS attack vector is exfiltrating sensitive data, such as social security numbers, personally
identifiable information (PII), or credit card info, and performing unauthorized operations, such as bank
transactions.
Once the attacker has access to the personal or sensitive information of users, they can demand ransom
payments from the organization to delete the data, or leak the information of their customers.

Breaches Enabled by Cross-Site Scripting (XSS)

 British Airways

British Airways — the second-largest carrier airline in the United Kingdom —

faced a data breach in 2018. The breach affected 380,000 booking transactions
between August to September 2018. Thankfully, it was caught by researchers
from RiskIQ who reported it to British Airways, and they patched it later.

 Fortnite

Fortnite — the popular online video game by Epic Games — could face an attack
leading to a data breach in January 2019. The issue was a retired, unsecured
web page with a dangerous cross-site scripting vulnerability that allowed
attackers to get unlimited access to 200 million users. The likely purpose of
attackers is stealing the game’s virtual currency and recording the players’
conversations, which may provide a treasure of useful information for their
future attacks.

 eBay

eBay is a well-known marketplace for buying and selling products from or to

businesses and consumers. Though it had cross-site scripting vulnerabilities
many times in the past, a vulnerability present from December 2015 to January
2016 was very dangerous. It was dangerous because it was a simple
vulnerability that could have been easily harvested to wreak havoc on eBay
users. And since users usually buy or sell products on eBay, attackers could gain
access to users’ products, sell it to them at a discount, or steal their payment
details, etc.
3. Cross-Site Request Forgery (CSRF)
Cross-site request forgery (CSRF, sometimes pronounced “sea surf” and not to be confused with cross-
site scripting) is a simple yet invasive malicious exploit of a website. A CSRF attack occurs when an
attacker forces the victim to perform unintended actions on the web application. The victim first logs
into the web app, which has deemed the user and browser trustworthy. Therefore, the app will execute
malicious actions that the attacker tricks the victim into forwarding a request to the web app. The
motivation for CSRF ranges from simple pranks to enabling illicit financial transactions.

What is the Impact of CSRF Attacks?

When a website sends a data request to another website on behalf of a user along
with the user’s session cookie, an attacker can launch a Cross-Site Request Forgery
Attack, which abuses a trustful relationship between the victim’s browser and the
webserver.

In some cases, depending on the type of action, the attacker can gain full control of
the user’s account. If the compromised user has a privileged role within the
application, the attacker might be able to take full control of all the application’s
functionality and data, which is devastating to both the business and the user. The
result can be data theft, unauthorized fund transfers, damaged client relationships,
changed passwords and many more.

4. Session Fixation
Session fixation is a web-based attack technique where an attacker tricks the user into opening a URL
with a predefined session identifier. Session fixation attacks can allow the attacker to take over a victim’s
session to steal confidential data, transfer funds, or completely take over a user account.
A Session fixation attack is an attack that occurs when a malicious user sets up a fake session before the
legitimate users are able to log in. This leads to the entire system getting compromised and used to steal
sensitive data.

Session Fixation is an attack that permits an attacker to hijack a valid user session. The attack explores a
limitation in the way the web application manages the session ID, more specifically the vulnerable web
application. It involves forcing a user’s session ID to a specified value. Depending on the target web
application’s functionality, attackers may use various techniques to fix session ID values.Examples of
session fixation techniques include cross-site scripting exploits and reusing HTTP requests.

First, an attacker fixes the victim’s user session ID. Then, the user logs in and inadvertently exposes the
online identity. The attacker can then hijack the victim’s user identity using the fixed session ID value.

Any web application that authenticates users with sessions is vulnerable to session fixation attacks
without adequate defenses. Web apps that use session IDs typically use cookies, though they can also
use hidden form fields or URLs. Cookie-based user sessions are the most popular and the easiest to
compromise. Most fixation attacks target cookie-based sessions.
5. Local File Inclusion (LFI)
Local File Inclusion is an attack technique in which attackers trick a web application into either running
or exposing files on a web server. An LFI attack exploits the dynamic file inclusion mechanisms in a web
application. It may occur when a web application takes user input, such as a parameter value or URL,
and passes it to a file inclusion command. An attacker can use this mechanism to trick the app into
including a remote file containing malicious code.

Most web application frameworks enable file inclusion, which is useful primarily to package shared code
into different files for later reference by the application’s main modules. If a web app references a file
for inclusion, it might execute the code in the file explicitly or implicitly (i.e., by calling a specific
procedure). The application could be vulnerable to LFI attacks if the module-to-load choice is based on
HTTP request elements.

Commonly, it’s called Local File Inclusion (LFI) when the vulnerability allows files to be loaded on the
target server and Remote File Inclusion (RFI) when the attacker is able to load remote code in the
application, a technique that increases the chances of malicious code being executed on the target.

Impact of Exploited Local File Inclusion vulnerabilities

The impact of a Local File Inclusion attack can vary based on the exploitation and the read
permissions of the webserver user. Based on these factors, an attacker can gather usernames
via an /etc/passwd file, harvest useful information from log files, or combine this vulnerability
with other attack vectors (such as file upload vulnerability) to execute commands remotely.

Let’s take a closer look at three possible outcomes of local file inclusion:

1. Information disclosure
Although not the worst outcome of a local file inclusion vulnerability, information disclosure can
reveal important information about the application and its configuration. That information can be
valuable to an attacker to gain a deeper understanding of the application and can help them
detect and exploit other vulnerabilities.

2. Directory Traversal
A local file inclusion vulnerability can lead to Directory Traversal attacks, where an attacker will
try to find and access files on the web server to gain more useful information, such as log files.
Log files can reveal the structure of the application or expose paths to sensitive files.

An incorrectly configured server can give attackers access to user config files, giving them
access to other files on your server, or even gain administrator access.

If you want to learn more about directory traversal, we have a great article that covers this
vulnerability in more depth – Directory Traversal: Examples, Testing, and Prevention

3. Remote Code Execution

Combined with a file upload vulnerability, a Local File vulnerability can lead to remote code
execution. In this case the attacker would use LFI to execute the unwanted file.
To compound matters, an attacker can upload a file to the server to gain the ability to execute
commands remotely, resulting in the attacker being able to control the whole server remotely.

6. Security Misconfigurations
A security misconfiguration arises when essential security settings are either not implemented or
implemented with errors. Security misconfigurations are some of the most serious web application
vulnerabilities because they provide attacks with opportunities to infiltrate the application easily.
Attackers could exploit a wide range of security configuration vulnerabilities. These include unchanged
default configurations, data stored in the cloud, ad hoc or incomplete configurations, plaintext error
messages containing sensitive information, and HTTP header misconfigurations. Security
misconfigurations may be present in any operating system, library, framework, or application.

9 Common Types of Security Misconfiguration

The following are common occurrences in an IT environment that can lead to a security
misconfiguration:

1. Default accounts / passwords are enabled—Using vendor-supplied

defaults for system accounts and passwords is a common security
misconfiguration, and may allow attackers to gain unauthorized access to the
system.
2. Secure password policy is not implemented—Failure to implement a
password policy may allow attackers to gain unauthorized access to the
system by methods such as using lists of common username and passwords
to brute force a username and/or password field until successful
authentication.
3. Software is out of date and flaws are unpatched—Failure to update
software patches as part of the software management process may allow
attackers to use techniques such as code injection to inject malicious code
that the application then executes.
4. Files and directories are unprotected—Leaving files and directories
unprotected may allow attackers to use techniques such as forceful browsing
to gain access to restricted files or areas in the server directory.
5. Unused features are enabled or installed—Failure to remove unnecessary
features, components, documentation, and samples makes the application
susceptible to misconfiguration vulnerabilities, and may allow attackers to use
techniques such as code injection to inject malicious code that the application
then executes.
6. Security features not maintained or configured properly—Failure to
properly configure and maintain security features makes the application
vulnerable to misconfiguration attacks.
7. Unpublished URLs are not blocked from receiving traffic from ordinary
users—Unpublished URLs, accessed by those who maintain applications,
are not intended to receive traffic from ordinary users. Failure to block these
URLs can pose a significant risk when attackers scan for them.
 8. Improper / poor application coding practices—Improper coding practices
can lead to security misconfiguration attacks. For example, the lack of proper
input/output data validation may lead to code injection attacks which work by
injecting code that the application executes.
9. Directory traversal—allows an attacker to access directories, files, and
commands that are outside the root directory. Armed with access to
application source code or configuration and critical system files, a
cybercriminal can change a URL in such a way that the application could
execute or display the contents of arbitrary files on the server. Any device or
application that reveals an HTTP-based interface is possibly vulnerable to a
directory traversal attack. Learn more in our detailed guide to directory
traversal

Security Misconfiguration Examples: Real Like Misconfiguration Attacks

Here are a few real life attacks that caused damage to major organizations, as a result of
security misconfigurations:

 NASA authorization misconfiguration attack – NASA because vulnerable

to a misconfiguration in Atlassian JIRA. An authorization misconfiguration in
Global Permissions enabled exposure of sensitive data to attackers.
 Amazon S3 – many organizations experienced data breaches as a result of
unsecured storage buckets on Amazon’s popular S3 storage service. For
example, the US Army Intelligence and Security Command inadvertently
stored sensitive database files, some of them marked top secret, in S3
without proper authentication.
 Citrix legacy protocols attack – Citrix used an IMAP-based cloud email
server and became the target of IMAP-based password-spraying. IMAP is an
insecure, legacy protocol, and attackers exploited it to get access to cloud-
based accounts and SaaS applications. Using multi factor authentication
(MFA) could have stopped the attack.
 Mirai (未来) botnet – Mirai was a mega-scale botnet that infected network
devices like CCTV cameras, DVD devices and home routers. The botnet
exploited a misconfiguration in these devices – the use of insecure default
passwords. The botnet was used to carry out DDoS attacks of unprecedented
magnitude, which brought down websites like Twitter, Reddit, and Netflix.

7. XML External Entity (XXE) Processing

Is a web security vulnerability that allows an attacker to interfere with an application's processing of
XML data. An XXE attack occurs when an attacker abuses widely used features in XML parsers to gain
access to remote or local files, typically resulting in Denial of Service (DoS). Attackers can also use XXE
processing to carry out SSRF attacks, which force the web application to make external, malicious
requests. XXE can also enable attackers to scan ports and execute malicious code remotely.
8. Directory Traversal
Directory traversal, or path traversal, is an HTTP exploit. It exploits a security misconfiguration on a web
server, to access data stored outside the server’s root directory. A successful directory traversal attempt
enables attackers to view restricted files and sometimes also execute commands on the targeted server.

Directory traversal (also known as file path traversal) is a web security vulnerability that allows an
attacker to read arbitrary files on the server that is running an application. Directory traversal attacks, or
backtracking, involve exploiting how the web application receives data from a web server. Web apps
often use Access Control Lists (ACLs) to restrict user access to specific files within the root directory. A
malicious actor can identify the URL format the target application uses for file requests.

Malicious users can use this attack method to access secrets and sensitive information like passwords
and database credentials. They can also exploit the vulnerability to carry out further enumeration of the
system and obtain the information they need to enable a combined attack through vectors like LFI and
RFI.

COMMON SOLUTIONS FOR PREVENTING WEB APPLICATION VULNERABILITIES

The most effective way to prevent web application vulnerabilities is to test your applications for
vulnerabilities and remediate them. Here are four ways of identifying critical vulnerabilities in web
applications.

https://snyk.io/learn/application-security/static-application-security-testing/

 Static application security testing (SAST), or static analysis, is a testing methodology that
analyzes source code to find security vulnerabilities that make your organization’s applications
susceptible to attack. Static Application Security Testing (SAST) solutions scan source code for
vulnerabilities and security risks. Many web applications incorporate code scanning at multiple
stages of development, including while committing new code to the codebase and building new
releases.
What is Static Application Security Testing?

SAST is a set of technologies that analyze the application’s code, byte code, and binaries line by
line. As the analyzed code is transparent and available to the tool, Static Application Security
Testing is a white-box testing technique.

Static Application Security Testing offers:

 Accuracy when it comes to recognizing flaws in the code

 Identification of vulnerabilities specific to code
 Identification of weaknesses that can become severe security risks if they aren’t
remediated
The ability of SAST solutions to find the exact line of code that needs remediation can reduce
remediation time and effort for developers.

It is programming-language dependent.
SAST is usually rules-based and scan results can contain false positives, so the results must be
carefully analyzed and filtered to identify real security issues.

7 Stages of Static Application Security Testing

− SAST is a vulnerability scanning technique that focuses on source code, bytecode, or
assembly code.
− The scanner can run early in your CI pipeline or even as an IDE plugin while
coding.
− SAST tools monitor your code, ensuring protection from such security issues as
saving a password in clear text or sending data over an unencrypted connection.

Shortcomings of SAST solutions

Limitation 1: Inability to scan runtime applications

While SAST solutions can detect many common vulnerabilities like XSS, buffer
overflow, and SQL Injection, they are limited to vulnerabilities that occur in the
code itself. Unfortunately, many vulnerabilities in a runtime application do not
actually exist in the code, but only arise when the application is compiled. If you
rely solely on SAST solutions, you may release potentially vulnerable
applications.

As an exampleStatic Application Security Testing falls short when it comes to

finding issues connected to:

 Authentication (is the code vulnerable to brute force attacks, or is

a password reset as effective as it can be, etc.)
  Sensitive data storage and transmission (especially in cases when
it can’t tell the difference between sensitive and non-sensitive
data)
 Privilege escalation and lack of authorization
 Data privacy (making sure it masks certain sensitive information
when it’s displayed)
These issues become even more acute when dealing with a microservices
environment where much of the code actually sits between the different services.

Limitation 2: SAST needs access to source code

Some organizations don’t have access to the application’s source code. This is a
big issue as Static Application Security Testing is complex. For it to function
properly it needs a semantic understanding of the code. This includes the codes’
dependencies, configuration files, etc. and many of other pieces that are always
in motion. Most dependencies aren’t even written in the same programming
language. Can SAST understand all these moving pieces? While also being
swift, accurate, and have a low false-positives rate? Not exactly.

Limitation 3: The need for a different SAST instance for every coding
language

When an organization uses multiple code languages, multiple instances of SAST

solutions are needed.

That means all of them require separate maintenance and configuration. This
adds significant overhead.

Limitation 4: Limited coding language support

In addition to requiring a different SAST instance for each coding language used
in an organization, SAST is limited to specific coding languages. While SAST
providers are constantly adding support for new languages, there are some
languages that will never be supported and others where SAST falls short from
providing complete coverage.

As examples, the effectiveness of SAST is reduced when JavaScript, Python,

and other dynamically typed languages are used.

JavaScript is the standard programming language of the web, and web is the
most used computing platform ever built. SAST’s inability to work well with
JavaScript represents a significant limitation. There are over 1.6 billion websites
in the world. JavaScript is used in 95% of them.

Limitation 5: Disadvantages in a Microservices environment

Another issue with Static Application Security Testing tools is the Microservices
architecture. SAST solutions can’t work in a world of Microservices. That’s a
huge problem as most developers today use microservices architecture.
 Microservices architecture is highly maintainable and organized around business
capabilities.

Check out best ways to test Microservices security.

Limitation 6: False Positives

One of the biggest problems with SAST solutions is that they are prone to false
positives. Developers can get results that point out a lot of findings. Only it turns
out most weren’t actually exploitable, or relevant. These results take time to
examine and see if a flaw can damage your application or not.

 Dynamic Application Security Testing (DAST) is the process of analyzing a web application
through the front-end to find vulnerabilities through simulated attacks. it can test an
application that is deployed in a staging or production environment, and execute its code to
check for vulnerabilities. Automated DAST tools find vulnerabilities by sending numerous
requests, including unexpected and malicious inputs, to applications, and analyzing the results
to identify security vulnerabilities.

Dynamic application security testing (DAST) is a black-box testing method that scans applications
in runtime. It is applied later in the CI pipeline. DAST is a good method for preventing
regressions and doesn’t depend on a specific programming language.

Manual penetration testers usually perform similar tests to those performed by DAST tools,
using tools like Burp Suite, Fiddler, and Postman.

Types of DAST

DAST can be divided into mainly two types, as given below.

Automated DAST

The testing tool uses crawlers and the main URL to scan the application in automated DAST. The
tool will also monitor and audit entire web applications to find critical vulnerabilities. Every
accessed page in the application is logged along with its request and response from the server.

The automated DAST can be configured to check for denial of service and brute force attacks,
too however it will slow the main application or website. Therefore, denial of service and brute
force tests are generally made with the consent of the application owner.

Manual DAST
 In manual DAST, the testing is done related to the context of the application. An automated
DAST scan cannot find all the vulnerabilities in the system. Business logic vulnerabilities are
generally out of scope for automated DAST as the automated scan cannot be fine-tuned for
every application. Therefore, manual DAST is used.

The tester has to understand the application in depth which is in the testing scope, and then
create test cases depending on various scenarios which can be breached by a malicious user.
The request sent to the server can be genuine or a crafted one, and the response from the
server is captured manually by proxy tools. Due to this, application-specific manual DAST can
find critical vulnerabilities which cannot be found by automated DAST.

Why is DAST Important?

The source code of an application is primarily confidential; therefore, most attackers target a
web application in dynamic environments. Simulating those malicious attackers and
compromised environments during DAST can help an organization find a bug before the
application is released. Modern web application architectures also induce misconfigurations as
not every developer is aware of them. With DAST, many security misconfigurations can be found
and removed from the application.

https://www.xenonstack.com/blog/application-testing-dast/

 IAST (interactive application security testing) analyzes code for security vulnerabilities while the
app is run by an automated test, human tester, or any activity “interacting” with the application
functionality. IAST solutions combine dynamic testing (similar to DAST tools) with static analysis
(similar to SAST tools) to help identify and manage security risks in web applications.

IAST solutions monitor application execution and gather information about functionality and
performance. They identify vulnerabilities in real time by deploying agents and sensors that
inspect running applications, and continuously analyzing all application interactions. In addition,
many IAST solutions incorporate software configuration analysis (SCA) to identify open source
components and frameworks and discover known vulnerabilities.

Interactive application security testing (IAST) solutions help detect and remediate vulnerabilities
in web applications, as part of an organization’s security testing toolset.
IAST involves using dynamic testing, also known as runtime testing, to monitor application
performance. IAST solutions instrument applications during runtime, using specialized
sensors, to collect operational data and analyze user interactions with the application.
The IAST process can incorporate a combination of automated security tests, customized tests
defined by the organization, or software composition analysis (SCA) to analyze open source
components and find known vulnerabilities.

IAST Benefits and Drawbacks

Here are notable benefits of IAST:

  Scans code in production—SAST tools often result in numerous false
positives. For example, reporting a line of code can that was already
addressed in another area of the code. IAST scan code in production
while focusing only on issues that truly matter.
 Scans code in development—IAST can help shift security checks to the
left by checking specific issues during development. For example, IAST
tools with IDE integration can offer quick feedback on features in
development.
 Quick remediation—IAST helps link issues with specific code locations.
It enables developers to quickly click through an application to find
specific problems and gain insights into quick remediation
recommendations.

Here are notable drawbacks of IAST:

 Programming-language dependent—IAST tools are often bound to

specific technologies that may not fit your scenario. Additionally, some
tools may require changing your code to include the vendor’s sensor
modules.
 Time intensive—IAST requires building and executing the tested
application, which takes more time overall. If you use IDE plugins, you
can leverage the quick feedback to catch issues during development.
However, it can take longer when building big test suites that run on all
production releases.
 Does not provide complete code coverage—IAST scans only executed
code to help reduce the number of false positives. It means the test does
not cover all the code, including any code that was accidentally released
without going through a quality assurance check.

 A penetration test, also known as a pen test, is a simulated cyber attack against your computer
system to check for exploitable vulnerabilities. Penetration testing is a security technique that
combines human security expertise with dynamic scanning tools to find vulnerabilities in web
application security mechanisms.

Penetration testers operate from an attacker’s perspective. They perform reconnaissance,

attempt to exploit vulnerabilities, gain unauthorized access, and demonstrate their ability to
steal data or disrupt services. However, they operate ethically, without causing actual harm to
the organization and within the scope of an agreement with the web application owner.

The term penetration testing (pentesting) refers to processes, tools, and services designed and
implemented for the purpose of simulating attacks and data breaches, and finding security
vulnerabilities. You can run a pentest for a computer system, an entire network, or a web
application.
The main goal of a pentest is to discover vulnerabilities that attackers can exploit. There are
several ways to discover these vulnerabilities. You can opt for manual pentests performed by a
team of white hat hackers, or automated penetration testing performed by a software solution.

The penetration testing process typically involves several phases. First, the tester (or solution)
gathers information about the target and identifies possible entry points. Then, the tester
attempts to breach the tested environment. Finally, the tester compiles a report detailing
vulnerabilities found and suggestions for improving security of the tested environment.

Web Application Penetration Testing

The purpose of a web application pentest is to identify security weaknesses or vulnerabilities in
web applications and their components, including the source code, the database, and any
relevant backend network.

A web application penetration testing process typically performs the following three phases:

 Reconnaissance—gathering information about the application. For example, the

operating system (OS) and resources the application uses.
 Discovery—attempts are made to detect vulnerabilities.
 Exploitation—using the detected vulnerabilities to gain unauthorized access to
the application and its pools of data.
The results of a web application pentest should provide information about detected
vulnerabilities and any successful exploitation. This information can help the organization
prioritize vulnerabilities and determine how to apply fixes.

What is Web Application Penetration Testing?

Web application penetration testing, also known as pentesting, simulates attacks against your
web applications, to help you identify security flaws and weaknesses so they can be remediated.
You can use penetration tests to detect vulnerabilities across web application components and
APIs including the backend network, the database, and the source code.

A web application penetration testing process provides a detailed report with security insights.
You can use this information to prioritize threats and vulnerabilities and define a remediation
strategy.

Types of Penetration Testing for Web Applications

When you run a pentest for web applications, there are several aspects you need to consider.
These aspects determine the location and the type of attack.

Here are the main differences between external and internal pentesting:
  External pen testing—attacks the application from the outside. The test
simulates how an external attacker would behave when launching an attack.
You can perform an external pentest to check firewalls and servers.
 Internal penetration testing—attacks launched from within the organization.
This is typically performed through LAN connections. The goal is to identify
vulnerabilities that might exist within the firewall, simulating an attack by a
malicious insider.
In addition to location of the attacker, there are other aspects to consider, such as levels of
access and scope of knowledge. Below are three main types of pentesting you can run:

 Black box penetration testing—simulate attacks launched by external actors,

with no prior knowledge of the targeted system.
 Gray box penetration testing—simulates attacks launched by internal actors,
with user-level access to certain systems.
 White box penetration testing—a comprehensive pentest that simulates
attacks launched by someone with root-level or administrator access and
knowledge.
REFERENCES:

 8 Critical Web Application Vulnerabilities and How to Prevent Them. (2022, May 30). Bright

Security. https://brightsec.com/blog/web-application-vulnerabilities/

 ‌3 Dangerous Cross-Site Scripting Attacks of the Last Decade. (2020, December). ReadWrite.

https://readwrite.com/3-dangerous-cross-site-scripting-attacks-of-the-last-decade/
 ‌SQL Injection Attack: Real Life Attacks and Code Examples. (2022, April 8). Bright Security.
https://brightsec.com/blog/sql-injection-attack/#:~:text=7%2DEleven%20breach%E2%80%94a
%20team,the%20IT%20security%20company’s%20website.

 Preventing CSRF Attacks | Veracode. (2021). Veracode. https://www.veracode.com/blog/secure-

development/preventing-csrf-attacks

 ‌SQL Injection. (2022). W3schools.com. https://www.w3schools.com/sql/sql_injection.asp

 ‌Cross Site Scripting (XSS) | OWASP Foundation. (2022). Owasp.org. https://owasp.org/www-

community/attacks/xss/

 ‌Session fixation | OWASP Foundation. (2022). Owasp.org. https://owasp.org/www-

community/attacks/Session_fixation

 ‌Local File Inclusion: Understanding and Preventing Attacks. (2021, December 13). Bright

Security. https://brightsec.com/blog/local-file-inclusion-lfi/

 ‌Security Misconfigurations: Definition, Causes, and Avoidance Strategies. (2022). Reciprocity.

https://reciprocity.com/blog/security-misconfigurations-how-to-avoid-them/#:~:text=explore

%20those%20issues.-,What%20Is%20a%20Security%20Misconfiguration%3F,a%20cyber

%20attack%20or%20breach.
  ‌What is XXE (XML external entity) injection? Tutorial & Examples | Web Security Academy.

(2022). Portswigger.net. https://portswigger.net/web-security/xxe#:~:text=XML%20external

%20entity%20injection%20(also,application’s%20processing%20of%20XML%20data.

 ‌What is directory traversal, and how to prevent it? | Web Security Academy. (2022).

Portswigger.net. https://portswigger.net/web-security/file-path-traversal

 ‌What Is SAST and How Does Static Code Analysis Work? | Synopsys. (2022). Synopsys.com.

https://www.synopsys.com/glossary/what-is-sast.html

 What is Dynamic Application Security Testing (DAST) | Micro Focus. (2019). Microfocus.com.

https://www.microfocus.com/en-us/what-is/dast

 ‌What is IAST? Interactive Application Security Testing | Veracode. (2020, December 7).

Veracode. https://www.veracode.com/security/interactive-application-security-testing-iast

 ‌What is Penetration Testing | Step-By-Step Process & Methods | Imperva. (2019, December 29).

Learning Center. https://www.imperva.com/learn/application-security/penetration-testing/

‌
‌