APPLICATION SECURITY
HCSC801
MODULE 2: DEFENCE AND TOOLS
BE EXTC, SEM-VII
Honours/ Minor degree Program in
CYBER SECURITY
Mrs. Arti Sawant
2
SECURING MODERN WEB APPLICATIONS
● Website vs WebApp:
Website WebApp
Websites are static HTML, Web Applications are the
CSS, with some JS files programs which can accept
displayed according styling form submissions, generate
provided in CSS pages dynamically
Websites aren’t dynamic, they It communicate with database
can’t submit forms, can’t to do CRUD (Create, Read,
generate pages dynamically Update and Delete) processes
and might be limited in other and more
accepts too.
3
CONSIDERATIONS TO BE TAKEN CARE FOR WEB APP
DEPLOYMENT
● Never put Debug mode ON in production: Many web
frameworks like WordPress, Django, Larvel provide a
development server which should be never used in
[Link] mode ON provides better error logs, with
the availability of information such as variable names and line
numbers from the source code for developers but keeping it on
during production may result in impact on performance,
expose sensitive data or create security vulnerabilities.
● Restrict Access to server and close unused ports:
Running our web app in cloud is very good option. Some of the
good options are Digitalocean, google cloud, azure and AWS.
When you rent for the virtual server limit the people who can
access to the server. its better to use SSH to access the server.
Always close unnecessary ports while running the server.
4
● Keep the Database secure: Many times we miss that
database is also the part of our application and its also
necessary for us to keep our database secure. Always
keep strong passwords, limit users who can have access
to run native commands with the database. Its also very
good to choose the database according to application
need.
● DNS hosting: DNS is the backbone of internet, its the
phonebook for the internet. In simple word DNS is the
protocol which converts human readable [Link]
necessary for our web app to have better and widespread
DNS like Cloudflare, cloud based DnS which reduces the
lookup time to find our server IP and to connect to it.
● Always update frameworks and application:
Updates are the best way to reduce bugs in our
application. in the same manner updating the framework
we used to build the application might be helpful but
sometimes we have to rewrite the code for our
application but if the update is long term it would be best5
to do it even we have to rewrite the code.
● Limiting API usage: Many of the webapp use external
services which will be included using specially
configured API’s for specific functions. Most of API
providers limit the usage according to their plan and its
also better for web app developers also to implement
rate limiting of API’s according to need so that we don’t
pay any extra.
● Bot and Spam: Many web application also contain
forms for allowing to subscribe email, or some other
query form, Many bots these days have the ability to
submit the plain forms. To protect its better to keep
recaptcha with every form which will keep most of the
bots out. Google provides recaptcha for free for basic
usage.
● HTTP headers: Most of the web application
frameworks allow to send HTTP headers like HSTS, CSP,
Referrer and Permission Policy, which helps the browser
determine the sources and protocols it should allow to 6
load styles, sources and media in turn hardening the
security of webapps like upgrading to HTTPS, XSS
SECURE WEB APPLICATION ARCHITECTURE
Figure shows a simple web application architecture. The
application’s web server and database server share the
same host machine. This architecture is very simple and
useful for early stages of project development. However,
it is not good enough for production applications as it
introduces a single point of failure.
7
● Figure below shows separation of the database
server from the web server
8
Multi-tier (N-tier) architecture
● It separates different components of the application into
multiple tiers/layers according to their functions. Each
tier generally runs on a different system. This provides
compartmentalization and avoids a single point of
failure.
9
Primary advantages of multi-tier secure web
application architecture
● Eliminates single point failure
● The use of a load balancer to distribute the traffic
among multiple web servers helps eliminate the web
server as a single point of failure
● The introduction of a DB cluster also helps eliminate
the database server as a single point of failure
● The implementation of several tiers helps to enhance
a secure web application architecture.
● The absence of a single point of failure limits the
attacker’s chances of taking control of the entire
application.
10
ATTRIBUTES OF SECURE WEB
APPLICATION ARCHITECTURE
● Inter-tier authentication,
● Server-side validation,
● Secure communication,
● Data at rest,
● Logging.
11
1. Inter-tier authentication
● Multi-tier architecture results in different
tiers/components of an application interacting with
each other
● Application tiers should authenticate with each other
● This ensures that an attacker cannot impersonate
the identity of other communicating
tiers/components. Secure inter-tier authentication
can be achieved using following mechanisms:
- Kerberos
- Mutual SSL
- IP validation
12
2. Server-side validation
● Data validation can occur on the client side (web
browser) and the server side (web server).
● Implementation of only client-side validation is not
enough to protect against malicious users.
● Attacker can create their own requests. Or, modify
existing requests to send to the server
independently from the web browser client.
● To protect the application from user-provided
malicious data, implement server-side validation
along with client-side validation. The implementation
of server-side validation prevents attackers from
accessing the application through alternate means
(e.g., proxy) to bypass client-side validation.
13
3. Secure communication
● Applications should use HTTPS to encrypt traffic over
the network. HTTPS provides an end-to-end secure
connection between the client application (browser)
and the server.
● TLS and SSL are the two common protocols used to
protect the confidentiality and integrity of the
communication over HTTPS.
● At a high level, a server uses valid SSL certificates
provided by a Certificate Authority to identify itself to
a browser. The browser and server then generate a
shared secret which is used to encrypt all network
communications.
● If HTTPS is not enabled on the application server, the
traffic between the browser and server flows over a
non-encrypted connection. This helps an attacker
14
retrieve sensitive information.
4. DATA AT REST
● Protect any data stored at rest within a back-end database
server.
● The data could exist in many formats, such as: financial
information, personally identifiable information (PII), and
personal health records. This makes the protection of data
stored at rest critically important.
● The common considerations when protecting data at rest
are;
- Use strong encryption algorithms (e.g., AES) to protect
data.
- Do not create your own cryptographic algorithm or its
implementation. Instead, use and implement algorithms
widely accepted by the cryptographic community.
- Use a strong (128 bit or higher) encryption key.
- Avoid storage of sensitive data within configuration files.
- If it is necessary to store the data within temporary files
15
during data transmission or the extract-transform-load
(ETL) process, store data temporarily and clear it from the
temporary location.
5. LOGGING
● It an essential part of web application security.
● Log files help identify security incidents and provide
information about application problems and unusual
conditions that the application may face.
● If the application or user account comes under attack,
information logged by application within log files will be
pivotal in understanding the attack and, in some cases,
tracing it back to the attacker.
● A logging system is a huge benefit for developers and
system administrators. Designing and maintaining it
carefully with the following considerations:
- An application must log security events (e.g., successful or
failed authentication events)
- An application must not log any sensitive information (e.g.,
login credentials, PII, credit card etc.)
- Store logs using strong encryption algorithms
- Access control restrictions must be in place to restrict access
16
to log files. Only the application should have write access to
it.
REVIEWING CODE FOR SECURITY
Automated code review is a process in which a tool
automatically reviews the source code of an application, using
a predefined set of rules to look for inferior code. Automated
review can find issues in source code faster than identifying
them manually.
Implementation
of Secure Web Secure Code
Application Review
Architecture
17
NEED FOR REVIEW
Secure code review is a critical process employed by the most
successful development teams. It can:
● Reduce the number of delivery defects found at a later stage in
the SDLC
● Decrease the amount of time developers spend fixing late-
stage defects, thereby increasing productivity
● Reduce the number of bugs and security vulnerabilities going
into production
● Improve consistency across codebases and increase
maintainability
● Improve collaboration, knowledge sharing, and developer
productivity, and lessons learned can help inform future code
development
● Improve ROI by helping make processes faster and more18
secure, and use less resources and time
ELEMENTS OF SECURE CODE REVIEW
The key components involved in successful secure
code review include:
● A combination of manual and automated review
● Collaboration, including sharing of knowledge
and lessons learned
● A study of metrics, which helps reduce defects
and policy violations before merging the code
19
VULNERABILITY DISCOVERY
● "Vulnerability discovery" in web application security
refers to the process of identifying and locating
weaknesses or flaws within a web application that
could potentially be exploited by attackers
● It is allowing them to gain unauthorized access to
data or systems, often through techniques like
manual code review, automated scanning tools, or
penetration testing.
● Common vulnerabilities: SQL injection, Cross-Site
Scripting (XSS), broken authentication, insecure
direct object references, sensitive data exposure,
security misconfigurations, and missing function
level access control 20
CONTD..
Discovery methods:
● Manual code review: Expert security analysts
manually examine application code to identify
potential vulnerabilities.
● Automated scanning tools: Specialized software
scans web applications for known vulnerabilities
based on predefined rules and patterns.
● Penetration testing (Pen testing): Simulates
real-world attacks to actively identify vulnerabilities
by attempting to exploit potential weaknesses in the
application.
21
DEFENDING AGAINST XSS ATTACK
1 Variable Validation
● It is a technique for determining whether an input satisfies
your desired criteria.
● By doing this, you may lower the possibility of harmful
information wreaking havoc in your application by ensuring
that only secure and correctly structured data passes
through.
● Use filters or regular expressions, for example, to ensure
that an email address looks like one that is expected from a
user.
2. Output Coding:
● When user display dynamic content on your website (like
user comments or messages), you need to encode it
properly before rendering it in HTML.
● Encoding means converting special characters to harmless
equivalents so the browser doesn’t interpret them as code.22
● Encoding ensures that script tags in a user’s submissions
show as ordinary text rather than being executed as
CONTD.
3. HTML Sanitization:
● It is the process of removing any scripts or components that
might be hazardous from user-generated HTML
● Before user input is shown on your website, HTML
sanitization acts as a safety net, removing or neutralizing
any possible risks.
● It will filter away any dangerous components or attributes
from a blog post that contains HTML code, ensuring that
only safe material is displayed to users. By doing this, you
maintain the safety of your website and safeguard users
from potentially dangerous activities.
4. Other XSS Controls
● Validation, encoding and sanitization are primary XSS
prevention techniques, but others can help limit damage
from inadvertent mistakes.
● These include cookie attributes, which change how
23
JavaScript and browsers can interact with cookies, and a
content security policy allowlist that prevents content from
being loaded
TUTORIAL QUESTIONS:
[Link] XXE attacks can be defended?
[Link] Injection attacks can be defended?
[Link] DoS attacks can be defended?
[Link] CORS based attacks can be prevented?
24
2. DEFENDING AGAINST XXE
● XXE is indeed easy to defend against—simply disable external entities in
your XML parser
25
CONTD.
● Depending on your application’s use cases, it may be possible to
re-architecture the application to rely on a different data format
rather than XML. This type of change could simplify the
codebase, while eliminating any XXE risk.
● Typically, XML can be interchanged with JSON, making JSON the
default when looking at other formats.
● JSON, on the other hand, would not be practical if your
application is parsing actual XML, SVG, or other XML-derived file
types.
● be a practical solution if your application is sending standard
hierarchical payloads that just happen to be in XML shape
26
CONTD.
Benefits of using JSON:
● JSON is a much more lightweight format than XML.
● JSON offers less rigidity, but brings with it faster and
easier to work with payloads.
● JSON maps to JavaScript objects, while XML more
closely maps to DOM trees (as the DOM is an XML-
derived format).
From this we can conclude that JSON should be an
acceptable alternative for any API that is dealing with
lightweight structured data to be interpreted by
JavaScript.
➢ Because XML has schema validation, it may also be
useful for applications where deeply rigid data 27
structure is required. JSON, on the other hand, is less
rigid, making it perfect for APIs with ongoing
DEFENDING AGAINST INJECTION
ATTACKS
● INJECTION attacks are still common (although more
common in the past), typically as a result of
improper attention on the part of the developer
writing any type of automation involving a CLI and
user-submitted data
● Covers a wide surface area
● Injection can be used against CLIs or any other
isolated interpreter running on the server (when it
hits the OS level, it becomes command injection
instead)
● Different Injection attacks:
- SQL Injection
- Cross site scripting
- OS Command injection attack
28
- Code injection attack
- Server side template injection
- HTTP header injection
PREVENTION AGAINST INJECTION
ATTACKS
● First practice, to write a strong code that can not be
edited by third party
● Validate user inputs
● Limit access to essential privileges: An attacker’s
ability to damage your network depends on their
access. You can limit their access by not always
allowing admin capabilities on database-connecting
platforms.
● Keeping sensitive data secure: An attacker’s ability
to damage your network depends on their access.
You can limit their access by not always allowing
admin capabilities on database-connecting
[Link] sure web app messages don’t
contain important information
29
● Control Who Accesses Your System: Injection attack
early detection through the use of penetration
testing; however, doing so will require more effort as
DEFENDING AGAINST DOS
● DoS attacks usually involve the use of system
resources, which can make detecting them a bit
difficult without robust server logging.
● It can be difficult to detect a DoS attack that
occurred in the past if it came through legitimate
channels
● A first measure against DoS-style attacks should be
building up a comprehensive enough logging system
in your server that all requests are logged alongside
their time to respond
● DoS attacks are structured to
- Exhaust server resources
- Exhaust client resources
- Request unavailable resources 30
PREVENTIONS:
● Network Segmentation: Segmenting the network
can help prevent a DoS attack from spreading
throughout the entire network. This limits the impact
of an attack and helps to isolate the affected
systems.
● Implement Firewalls: Firewalls can help prevent
DoS attacks by blocking traffic from known malicious
IP addresses or by limiting the amount of traffic
allowed from a single source.
● Use Intrusion Detection and Prevention
Systems: Intrusion Detection and Prevention
Systems (IDS/IPS) can help to detect and block DoS
attacks by analyzing network traffic and blocking
malicious traffic
31
● Limit Bandwidth: Implementing bandwidth
limitations on incoming traffic can help prevent a
DoS attack from overwhelming the network or
CONTD.
● Implement Content Delivery Network (CDN): A CDN
can help to distribute traffic and reduce the impact of a
DoS attack by distributing the load across multiple
servers.
● Use Anti-Malware Software: Anti-malware software
can help to detect and prevent malware from being used
in a DoS attack, such as botnets.
● Perform Regular Network Scans: Regular network
scans can help identify vulnerabilities and
misconfigurations that can be exploited in a DoS attack.
Patching these vulnerabilities can prevent a DoS attack
from being successful.
● Develop a Response Plan: Having a DoS response plan
in place can help minimize the impact of an attack. This
32
plan should include steps for identifying the attack,
isolating affected systems, and restoring normal
operations.
CONTD.
● Cloud Mitigation Provider – Cloud mitigation providers are
experts at providing DDoS mitigation from the cloud. This
means they have built out massive amounts of network
bandwidth and DDoS mitigation capacity at multiple sites
around the Internet that can take in any type of network
traffic, whether you use multiple ISP’s, your own data center,
or any number of cloud providers. They can scrub the traffic
for you and only send “clean” traffic to your data center.
● Firewall – This is the simplest and least effective method.
Python scripts are often written to filter out malicious traffic,
or existing firewalls can be utilized by enterprises to block
such traffic.
● Internet Service Provider (ISP) – Some enterprises use
their ISP to provide DDoS mitigation. These ISPs have more
bandwidth than an enterprise would, which can help with 33
large volumetric attacks.
DEFENSE AGAINST CORS ATTACK
1. The victim visits [Link] while being authenticated to
[Link].
2. [Link] dumps a malicious script designed to interact
with [Link], on the victim’s machine.
3. The victim unwittingly executes the malicious script, and the
script issues a cross-origin request to [Link]. In this
example, let’s assume the request is crafted to obtain the
credentials necessary to perform a privileged action, such as
revealing the user’s password.
4. [Link] receives the victim’s cross-origin request
and the CORS header.
5. The web server will check the CORS header to determine
whether or not to send the data to [Link]. In this
example, we’re assuming that CORS is allowed with
authentication (Access-Control-Allow-Credentials: true).
34
6. The request is validated, and the data is sent from the victim’s
browser to [Link].
PREVENTION AGAINST CORS
Specify the allowed origins: If a web resource contains sensitive
information, the allowed origin(s) should be specified in full in the
Access-Control-Allow-Origin header (i.e., no wildcards).
Only allow trusted sites: While this one may seem obvious,
especially given the previous tip, but origins specified in the Access-
Control-Allow-Origin header should exclusively be trusted sites.
Don’t whitelist “null”: User should avoid using the header Access-
Control-Allow-Origin: null. While cross-domain resource calls from
internal documents and sandboxed requests can specify the “null”
origin, you should treat internal cross-origin requests in the same way
as external cross-origin requests. User should properly define your
CORS headers
Implement proper server-side security policies: CORS defines
browser behaviors and is never a replacement for server-side
protection of sensitive data. User should continue protecting sensitive
data, such as authentication and session management, in addition to
properly configured CORS. 35
