Module 4

Securing Network and Web Application

Content
● Application, Services and Servers Introduction,
● Basic security for HTTP
● Applications and Services,
● Basic Security for SOAP Services,
● Identity Management and Web Services,
● Patterns, Security Considerations, Challenges
Layers of Modern Web Application Architecture
Application Layer: Web Server

A web server runs one or more websites or web apps. The web server uses HyperText Transfer
Protocol (HTTP) along with other protocols to listen to user requests via a browser. It processes
them by applying business logic and delivering the requested content to the end-user.

A Web Server can be a hardware device or a software program.

● Hardware Web Server: A computer device that is connected to the internet and contains
web server software and web app components such as images, HTML docs, JS files and CSS
style sheets.
● Software Web Server: It is software that understands URLs and HTTP protocols. Users can
access it via domain names to receive the requested content.

Apache is a popular open-source web server from Apache Software Foundation

NGINX is another popular web server that is usually pronounced as ‘Engine X’.
Presentation Layer: Client-side Component
(Front-end)

The client-side component of a web application architecture enables users to

interact with the server and the backend service via a browser. The code
resides in the browser, receives requests and presents the user with the
required information. This is where UI/UX design, dashboards, notifications,
configurational settings, layout and interactive elements come into the
picture.
Here are some of the commonly used front-end technologies:
Application Layer: Server-side Component (Back-end)

The server-side component is the key component of the web application

architecture that receives user requests, performs business logic and delivers the
required data to the front-end systems. It contains servers, databases, web
services etc.
Here are some of the commonly used Server-side technologies:
Data Layer: Database

A database is a key component of a web application that stores and manages information for a
web app. Using a function, you can search, filter and sort information based on user request
and present the required info to the end user. They allow role-based access to maintain data
integrity.

While choosing a database for your architecture of web app, the size, speed, scalability and
structure are the four aspects that require your consideration. For structured data, SQL-based
databases are a good choice. it suits financial apps wherein data integrity is a key requirement.

To handle unstructured data, NoSQL is a good option. It suits apps wherein the nature of
incoming data is not predictable. Key Value databases associate each value with a key and suit
databases that store user profiles, reviews, blog comments etc. For analytics, Wide Column
databases are a good choice.
Attacks on Web Applications
SQL Injection: SQL injection attacks are when an attacker uses a web form field or URL
parameter to gain access to or manipulate your database. When you use standard Transact SQL
it is easy to unknowingly insert rogue code into your query that could be used to change tables,
get information and delete data. You can easily prevent this by always using parameterised
queries, most web languages have this feature and it is easy to implement.

Cross-site scripting (XSS) attacks:Cross-site scripting (XSS) attacks inject malicious

JavaScript into your pages, which then runs in the browsers of your users, and can change page
content, or steal information to send back to the attacker. For example, if you show comments
on a page without validation, then an attacker might submit comments containing script tags and
JavaScript, which could run in every other user's browser and steal their login cookie, allowing
the attack to take control of the account of every user who viewed the comment. You need to
ensure that users cannot inject active JavaScript content into your pages.
Top 10 Web Application Security Risks
HTTP headers
The HTTP headers are used to pass additional information between the clients and the server
through the request and response header. All the headers are case-insensitive, headers fields are
separated by colon, key-value pairs in clear-text string format. The end of the header section
denoted by an empty field header. There are a few header fields that can contain the comments.
And a few headers can contain quality(q) key-value pairs that separated by an equal sign.

There are four kinds of headers context-wise:

● General Header: This type of headers applied on Request and Response headers both but
with out affecting the database body.
● Request Header: This type of headers contains information about the fetched request by the
client.
● Response Header: This type of headers contains the location of the source that has been
requested by the client.
● Entity Header: This type of headers contains the information about the body of the
resources like MIME type, Content-length.
Use the developer tools in a browser: To check HTTP header

1. Open DevTools by pressing Control+Shift+I or Command+Option+I (Mac).

2. Click the Network tab. Right now the Network panel is empty.
3. Reload the page to log some network activity. Each row represents a resource. The
top resource is usually the main HTML document.
4. Click a resource and open the Headers tab to view the HTTP headers.
5. In the HTTP headers, look for the Content-Type header, and in particular for the
charset parameter.
Security of HTTP

HTTP is used to communicate over the internet, so users, information

providers, and application developers should be aware of the limitations
of security in HTTP/1.1. This section does not provide a definitive
solution to the problems mentioned here. It provides some suggestions
to reduce security risk.
Security of HTTP

In HTTP, clients are often privy to a large amount of personal information like: name
of the user, email address, passwords, location, Encryption key, etc. We should be
careful to prevent unintentional leakage of this personal information of the client via
the HTTP protocol to other sources.
● All the confidential information should be stored at the server in encrypted form.
● Revealing the specific software version of the server might allow the server
machine to become more vulnerable to attacks against software that is known to
contain security holes.
● Proxies that serve as a portal through a network firewall should take special
precautions regarding the transfer of header information that identifies the hosts
behind the firewall.
Attacks Based On File and Path Names
The implementation of the origin server of HTTP should be careful to restrict the document, which is returned by HTTP
requests to be only that were intended by the server administrators.

For example, Microsoft Windows, UNIX, and other operating systems use "--" as a path component which shows a directory
level above the current one. On that type of system, an HTTP server MUST disallow any such construct in the Request-URI if
it would, otherwise an HTTP server disallow access to a resource those intended to be accessible through the HTTP server.

DNS Spoofing

HTTP clients rely heavily on the DNS (Domain name service), and are thus generally prone to security attacks, which are
based on deliberate mis-association of IP addresses and the name of the DNS. So the client should be careful in assuming the
continuing validity of an IP address and DNS name association.

If the clients of HTTP cache the results of hostname lookups to improve the performance, they must observe the TTL
information, which was reported by the DNS. When the IP address of the previously accessed server is changed, then the
HTTP clients could be spoofed if they do not observe this rule.
Authentication Credentials and Idle Clients

User-agent and existing HTTP clients typically retain the information of authentication indefinitely. HTTP/1.1 does not
provide any method for a server to direct clients to discard these cached credentials.To solve this problem, we can encourage
the use of idle timeout, password protection, and other methods that reduce the security problems inherent in this problem.

Location Headers and Spoofing

If the multiple organizations are supported by a single server, and any of the organizations do not trust each other, then it must
check the Location value and Content-Location headers in the response that are generated under control of said organizations.
These organizations are used to make sure that they do attempt to invalidate resources over which they have no authority.
HTTP Security
● Content Security Policy (CSP)
● Threats

Mitigating cross-site scripting

Mitigating packet sniffing attacks

Using CSP
● Content Security Policy (CSP)

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate
certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. These
attacks are used for everything from data theft, to site defacement, to malware distribution
Content Security Policy (CSP) is about creating a whitelist of "things that are allowed to happen"
on your website.
 ● Content Security Policy (CSP)

The idea is that if you only allow the good things, then the bad things can no longer happen.
The bad thing that CSP tries to prevent is a web vulnerability called Cross Site Scripting (XSS).
XSS is a very prolific web vulnerability that is used in a number of attacks including account
compromises, worms, credit card skimming and more.
CSP is designed to be fully backward compatible (except CSP version 2 where there are some
explicitly-mentioned inconsistencies in backward compatibility; more details here section 1.1).
Browsers that don't support it still work with servers that implement it, and vice versa: browsers
that don't support CSP ignore it, functioning as usual, defaulting to the standard same-origin
policy for web content. If the site doesn't offer the CSP header, browsers likewise use the standard
same-origin policy.
To enable CSP, you need to configure your web server to return the Content-Security-Policy
HTTP header. (Sometimes you may see mentions of the X-Content-Security-Policy header
What does Content Security Policy (CSP) look like?

Content-Security-Policy is an HTTP header. This is what the browser receives

default-src 'none';

script-src 'self' 'report-sample' https://www.google-analytics.com;

style-src 'self' https://cdn.bootstrap.com;

report-uri https://demo.endpoint.csper.io/;

In this policy, javascript is allowed to be loaded from 'self' (the server that sent this policy), or google-analytics. CSS
is allowed to be loaded by self, or cdn.bootstrap.com. Any violations of this policy is wrapped up into a json blob
and sent to demo.endpoint.csper.io.
Content Security Policy Examples

script-src 'self' https://www.google-analytics.com;

style-src 'self' https://cdn.bootstrap.com;

This policy includes two different directives: script-src, style-src.

The script-src and style-src specify where javascript and CSS are allowed to be loaded from.

self is a keyword that means that resources can be loaded from the same origin.
Generic Unsafe Policy

default-src 'none';
script-src 'self' 'unsafe-inline' 'unsafe-eval' https://www.google-analytics.com;

By default Content Security Policy does not allow inline javascript. This means you can not directly embed javascript into
your HTML files. This is because most client side attacks involve maliciously injecting javascript into HTML, so they are
blocked by CSP.

You can relax this restriction by including the unsafe-inline keyword in your script-src (and/or style-src). Keep in mind this
defeats the purpose of CSP (info).
Content Directives
Open cmd and execute the following command

start chrome --auto-open-devtools-for-tabs

Mitigating cross-site scripting
A primary goal of CSP is to mitigate and report XSS attacks.

XSS attacks exploit the browser's trust in the content received from the server. Malicious
scripts are executed by the victim's browser because the browser trusts the source of the
content, even when it's not coming from where it seems to be coming from.

CSP makes it possible for server administrators to reduce or eliminate the vectors by which
XSS can occur by specifying the domains that the browser should consider to be valid sources
of executable scripts.

A CSP compatible browser will then only execute scripts loaded in source files received from
those allowed domains, ignoring all other scripts (including inline scripts and event-handling
HTML attributes).
Mitigating packet sniffing attacks

In addition to restricting the domains from which content can be loaded, the server can specify

which protocols are allowed to be used; for example (and ideally, from a security standpoint), a

server can specify that all content must be loaded using HTTPS. A complete data transmission

security strategy includes not only enforcing HTTPS for data transfer, but also marking all

cookies with the secure attribute and providing automatic redirects from HTTP pages to their

HTTPS counterparts. Sites may also use the Strict-Transport-Security HTTP header to ensure that

browsers connect to them only over an encrypted channel

Using CSP

Configuring Content Security Policy involves adding the Content-Security-Policy HTTP header
to a web page and giving it values to control what resources the user agent is allowed to load
for that page. For example, a page that uploads and displays images could allow images from
anywhere, but restrict a form action to a specific endpoint. A properly designed Content
Security Policy helps protect a page against a cross-site scripting attack. This article explains
how to construct such headers properly, and provides examples.
Specifying your policy

You can use the Content-Security-Policy HTTP header to specify your policy, like this:

Content-Security-Policy: policy

A policy is described using a series of policy directives

Default-src

Child-src

Connect-src

Default-src

Font-src

Frame-src

Img-src

manifest-src
Examples: Common use cases

Example 1
A web site administrator wants all content to come from the site's own origin (this excludes subdomains.)
Content-Security-Policy: default-src 'self'
Example 2
A web site administrator wants to allow content from a trusted domain and all its subdomains (it doesn't have to be the
same domain that the CSP is set on.)
Content-Security-Policy: default-src 'self'; img-src *; media-src example.org example.net; script-src
userscripts.example.com
Example 3
A web site administrator wants to allow users of a web application to include images from any origin in their own content,
but to restrict audio or video media to trusted providers, and all scripts only to a specific server that hosts trusted code.
Content-Security-Policy: default-src 'self'; img-src *; media-src example.org example.net; script-src
userscripts.example.com
Strict-Transport-Security
The HTTP Strict-Transport-Security response header (often abbreviated as HSTS) informs browsers that the site should only be accessed
using HTTPS, and that any future attempts to access it using HTTP should automatically be converted to HTTPS.

Strict-Transport-Security: max-age=<expire-time>

Strict-Transport-Security: max-age=<expire-time>; includeSubDomains

Strict-Transport-Security: max-age=<expire-time>; includeSubDomains; preload

max-age=<expire-time>

The time, in seconds, that the browser should remember that a site is only to be accessed using HTTPS.
What is SOAP?

SOAP stands for Simple Object Access Protocol. It is a XML-based protocol for
accessing web services.

SOAP is a W3C recommendation for communication between two applications.

SOAP is XML based protocol. It is platform independent and language

independent. By using SOAP, you will be able to interact with other programming
language applications.
SOAP architecture shows the various building blocks of a SOAP Message.
Advantages of Soap Web Services

WS Security: SOAP defines its own security known as WS Security.

Language and Platform independent: SOAP web services can be written in any programming
language and executed in any platform.
Disadvantages of Soap Web Services

Slow: SOAP uses XML format that must be parsed to be read. It defines
many standards that must be followed while developing the SOAP
applications. So it is slow and consumes more bandwidth and resource.
WSDL dependent: SOAP uses WSDL and doesn't have any other
mechanism to discover the service.
What Does Web Server Security Mean?

Web server security refers to the tools, technologies and processes that enable information
security (IS) on a Web server. This broad term encompasses all processes that ensure that a
working Internet server operates under a security policy.

Web server security is the security of any server that is deployed on a Worldwide Web domain
or the Internet. It is implemented through several methods and in layers, typically, including the
base operating system (OS) security layer, hosted application security layer and network
security layer. OS security, which ensures access to authorized users only, operates a Web
server’s critical components and services. Application layer security ensures control over the
content and services hosted on the Web server. Network security provides protection against
Internet-based security exploits, viruses and attacks.

Secure Sockets Layer (SSL) certificates, HTTP Secure protocol and firewalling are several
tools and technologies used to implement Web server security.
WS-Security

Web Services Security (WS-Security) describes enhancements to SOAP messaging to provide

quality of protection through
● Authentication. (Username and Password)
● Confidentiality, (Encryption/Decryption)
● Integrity, (Signature)
● Non Repudiation.(Timestamp)
Authentication

This mechanism uses a security token to validate the user and determine whether a
client is valid in a particular context. A client can be a user, computer, or application.
Without authentication, an attacker can use spoofing techniques to send a modified
SOAP message to the service provider.

In authentication, a security token is inserted in the request message. Depending on the

type of security token that is being used, the security token can also be inserted in the
response message. The following types of security token are supported for
authentication:
 ● Authentication. (Username and Password)

Username Token Profile

X509 certificate

SAML
Username tokens
Username tokens are used to validate user names and passwords. When a web
service server receives a username token, the user name and password are
extracted and passed to a user registry for verification. If the user name and
password combination is valid, the result is returned to the server and the
message is accepted and processed. When used in authentication, username
tokens are typically passed only in the request message, not the response
message.
X.509 tokens are validated by using a certificate path.
The integration node support for SAML assertions is restricted to passing the token to a
WS-Trust Security Token Service (STS) for validation.

Kerberos tickets are validated against the host's Kerberos keytab file.

The integration node support for LTPA binary tokens is restricted to passing the token to
a WS-Trust STS for validation.

All types of token must be protected. For this reason, if you send them over an untrusted
network, take one of the following precautions:

● Use HTTPS
● Configure the policy set to protect the appropriate elements in the SOAP header
Issuance Fields

X.509 certificate fields contain information about the identity that the certificate is issued to as well as the identity of the issuer CA. The
standard fields include:

● Version – the X.509 version that applies to the certificate

● Serial number – the unique serial number identifier provided by the CA that distinguishes the certificate from others
● Algorithm information – the cryptographic algorithm used by the issuer to sign the certificate
● Issuer distinguished name – the name of the CA issuing the certificate
● Validity period of the certificate – the start/end date and time it's valid and can be trusted
● Subject distinguished name – the name of the identity the certificate is issued to
● Subject public key information – the public key associated with the identity
Integrity

This mechanism uses message signing to ensure that information is not changed,
altered, or lost accidentally. When integrity is implemented, an XML digital signature
is generated on the contents of a SOAP message. If unauthorized changes are
made to the message data, the signature is not validated. Without integrity, an
attacker can use tampering techniques to intercept a SOAP message between the
web service client and server, and modify it.
Confidentiality
This mechanism uses message encryption to ensure that no party or process can
access or disclose the information in the message. When a SOAP message is
encrypted, only a service that knows the appropriate key can decrypt and read the
message.
How To Build Secure Web Services

Regular Testing
In this IoT era, few people perform regular testing on all devices connected to their server networks. You must implement
testing procedures to ensure your SOAP API stands up to common threats and highlight vulnerabilities that hackers may
exploit. Some types of tests include injection testing and fuzz testing. The former determines how your API reacts to
unexpected input, while the latter detects vulnerable points where ransomware or malicious code can be introduced.

Identity and Access Management (IAM)

This is the basic layer of any cybersecurity protocol. It includes everything from usernames and passwords to advanced
authentication techniques like two-step verification. IAM should prevent external users from accessing the application outside
hours or stealing session tokens and gaining entry into the sessions.
Kerberos-based WS-Security

Kerberos is a network authentication protocol that enables mutual authentication with

symmetric keys. Users and services on a network authenticate with each other through
a Key Distribution Center (KDC), as a trusted third party. IBM® App Connect Enterprise
provides support for Kerberos either as a service or as a client.
Request Monitoring
Involves monitoring SOAP messaging and requests for abnormalities. You should, therefore, quickly identify and resolve any
data leaks or vulnerabilities. This uses logging systems, which you can regularly check for any irregularities.

Input Validation
In SOAP, input validation is divided into SOAP response validation and schema compliance validation. The former ensures
that the response to the SOAP message follows the correct format, and the latter ensures that the message follows XML
schema and the Web Service Description Language (WSDL).

Redundant Security Standards

There are many places of overlap in SOAP, XML, and WSDL standards. The purpose of redundant security standards is to
provide insurance in these areas of overlap. With them in place, you have less chance of exposing sensitive data and a better
chance of identifying vulnerabilities before hackers exploit them.