CSS Unit III Access Control & Web Security

Lanscape

By
Dr. Shruti Bharadwaj
CSE Department
 Access Control: Principle of Least Privileadge

• The principle of least privileadge is the idea that at any user, program, or
process should have only the bare minimum privileges necessary to perform
its function.
• For example, a user account created for pulling records from a database
doesn’t need admin rights, while a programmer whose main function is
updating lines of legacy code doesn’t need access to financial records.
• The principle of least privilege can also be referred to as the principle of
minimal privilege (POMP) or the principle of least authority (POLA).
 Access Control

• Access control is a method of restricting access to sensitive data.

• Only those that have had their identity verified can access company
data through an access control gateway.
• Components of Access Control
1) Authentication: The act of proving an assertion, such as the identity of a person or
computer user. It might involve validating personal identity documents, verifying
the authenticity of a website with a digital certificate, or checking login credentials
against stored details.
2) Authorization: The function of providing access rights.
3) Access: Once authenticated and authorized, the person or computer can access the
resource.
4) Manage: Managing an access control system includes adding and removing
authentication and authorization of users or systems..
5) Audit: Frequently used as part of access control to enforce the principle of lest
privileadge
Access Control Matrix
 Types of Access Control
• Discretionary access control (DAC):
Access management where owners or administrators of the protected
system, data or resource set the policies defining who or what is authorized
to access the resource. These systems rely on administrators to limit the
propagation of access rights. DAC systems are criticized for their lack of
centralized control.
• Mandatory access control (MAC):
Access rights are regulated by a central authority based on multiple levels of
security. MAC is common in government and military environments where
classifications are assigned to system resources and the operating system
or security kernel will grant or deny access based on the user's or the
device's security clearance. It is difficult to manage but its use is justified
when used to protected highly sensitive data.
 --Continue

• Role-Based Access Control:

In RBAC, an access system determines who can access a resource rather
than an owner. RBAC is common in commercial and military systems, where
multi-level security requirements may exist. RBAC differs from DAC in that
DAC allows users to control access while in RBAC, access is controlled at the
system level, outside of user control. RBAC can be distinguished from MAC
primarily by the way it handles permissions. MAC controls read and write
permissions based on a user/device's clearance level while RBAC controls
collections of permissions that may include complex operations such as
credit card transactions or may be as simple as read or write.
• Rule-based access control:
A security model where an administrator defines rules that govern access to
the resource. These rules may be based on conditions, such as time of day
and location. It's not uncommon to have some form of rule-based access
control and role-based access control working together.
 Unix and Windows Access control Summary

• Each process in UNIX has process ID, inherited from creating process and
process can change ID. Special root ID allowed all access.
• File has access control list(ACL), grants permission to user ID(Owner, group
and other.
• Each file has owner and group.
• Permissions set by owner are read, write and execute. Owner, group and
other. Represented by vector of four octal values.
• Only owner, root can change permission.
• Each process has three ids Real User ID, effective user ID and saved user ID.
 Weakness in Isolation and Privileges
• Network-facing Daemons
Root processes with network ports open to all remote parties, e.g., sshd,
ftpd, sendmail,
• Rootkits
System extension via dynamically loaded kernel modules
• Environment Variables
System variables such as LIBPATH that are shared state across applications.
An attacker can change LIBPATH to load an attacker provided file as a
dynamic library
• Shared Resources
Since any process can create files in /tmp directory, an untrusted process
may create files that are used by arbitrary system processes
• Time-of-Check-to-Time-of-Use (TOCTTOU)
Typically, a root process uses system call to determine if initiating user has
permission to a particular file, e.g. /tmp/X.
After access is authorized and before the file open, user may change the file
/tmp/X to a symbolic link to a target file /etc/shadow.
 Access Control in Windows
• Some basic functionality similar to Unix like specify access for groups and users , Read,
modify, change owner, delete.
• Some additional concepts of tokens and security attributes .
• Generally – More flexible than Unix because it can define new permissions and can give
some but not all administrator privileges
• Identify subject using SID that is Security ID (SID)
 Identity (replaces UID)
 SID revision number
 48-bit authority value
 variable number of Relative Identifiers (RIDs), for uniqueness
 Users, groups, computers, domains, domain members all have SID
• Process has set of tokens
o Security context
 Privileges, accounts, and groups associated with the process or thread
 Presented as set of tokens
o Impersonation token
 Used temporarily to adopt a different security context, usually of another user
o Security Reference Monitor
 Uses tokens to identify the security context of a process or thread
 --Continue
 Object has security descriptor

Security descriptor associated with an object specifies who can perform

what actions on the object
 Several fields

 Header contains descriptor revision number and control flags, attributes

of the descriptor – E.g., memory layout of the descriptor\
 SID of the object's owner

 SID of the primary group of the object

 Two attached optional lists: Discretionary Access Control List (DACL) –

users, groups, … and System Access Control List (SACL) – system logs, ..
 --Continue

Impersonation Tokens (compare to setuid)

 Process adopts security attributes of another and client passes
impersonation token to server.
 Client specifies impersonation level of server
 Anonymous : Token has no information about the client .
 Identification : Obtain the SIDs of client and client's privileges, but server
cannot impersonate the client .
 Impersonation : Impersonate the client .
 Delegation : Lets server impersonate client on local, remote systems
 More on Access Control

• The most common logical access control

• Sometimes referred to as a logical token
• A secret combination of letters and numbers that only the user knows
• A password should never be written down – Must also be of a sufficient length
and complexity so that an attacker cannot easily guess it (password paradox
• A strong password policy can provide several defenses against password
attacks
• The first password policy is to create and use strong passwords
• • One of the best defenses against rainbow tables is to prevent the attacker
from capturing the password hashes
• A final defense is to use another program to help keep track of passwords
 Attacks on Password

• A Brute force attack is a well known breaking technique, by certain records,

brute force attacks represented five percent of affirmed security ruptures. A
brute force attack includes ‘speculating’ username and passwords to
increase unapproved access to a framework. Brute force is a straightforward
attack strategy and has a high achievement rate.
• A dictionary attack is a method of breaking into a password-protected
computer, network or other IT resource by systematically entering every
word in a dictionary as a password. A dictionary attack can also be used in
an attempt to find the key necessary to decrypt an encrypted message or
document.
• A rainbow table attack is a type of hacking wherein the perpetrator tries to
use a rainbow hash table to crack the passwords stored in a database
system. A rainbow table is a hash function used in cryptography for storing
important data such as passwords in a database. Sensitive data are hashed
twice (or more times) with the same or with different keys in order to avoid
rainbow table attacks.
 Browser Isolation
• Browser isolation is a cybersecurity model for web browsing that can be
used to physically separate an internet user’s browsing activity from their
local machine, network and infrastructure.
• With this model, individual browser sessions are abstracted away from
hardware and direct internet access, trapping harmful activity inside the
disposable environment.
• Browser isolation may also be referred to as remote browser isolation, web
isolation or remote browsing.
• A major weakness in popular security tools is protection from web or
browser-based attacks, malware and ransomware.
• The development of browser isolation technology was meant to combat that
weakness.
• By separating browsing activity from endpoint hardware, the device’s attack
surface is reduced, sensitive data is protected and malware or other known
and unknown security threats are minimized.
• This is an evolution of the cybersecurity concepts of security through
physical isolation and air-gapping.
 How Does browser Isolation Works

• Browser isolation works by providing users with a disposable, non-persistent

environment for browsing.
• This can be executed through a variety of methods but typically
involves virtualization, containerization or cloud browsing.
• When a user closes the browsing session or the session is timed out, the
isolated environment is reset or discarded. Additionally, any malicious code
or harmful traffic is discarded as well, preventing it from ever reaching
the endpoint device or network.
• The browser isolation method treats all websites, files and content equally
by labeling them as untrusted or blacklisted unless otherwise specified.
• Within the isolated environment, files can be rendered remotely
or sanitized without the need to download them.
• This is different from other security methods that do not treat information
equally and filter content based on potential threatening signs.
 Web Security Definition, Goals and Threat Model

• Web security refers to protecting networks and computer systems from

damage to or the theft of software, hardware, or data. It includes protecting
computer systems from misdirecting or disrupting the services they are
designed to provide.
• It includes
 Browser Security Model

 Web Application Security

 Content Security policies

 Authentication and Session management

 HTTP:Goals and Pitfalls

 Web Security Goals

• Safely browse the web

• User should be able to visit varieties of websites without incurring harm
ssuch as no stolen harm or site A cannot harm session at site B.
• Support Secure web applications
• Applications delivered over the web should be able to achieve the same
security properties as stand-alone applications.
 Web Security Threat Model

• Threat modeling is a procedure for optimizing Network/ Application/ Internet

Security by identifying objectives and vulnerabilities, and then defining
countermeasures to prevent, or mitigate the effects of, threats to the
system.
• A threat is a potential or actual undesirable event that may be malicious
(such as DoS attack) or incidental (failure of a Storage Device).
• Threat modeling is a planned activity for identifying and assessing
application threats and vulnerabilities.
• Threat modeling allows you to apply a structured approach to security and to
address the top threats that have the greatest potential impact to your
application first.
• The threat model include
• Web Attacker
• Network Attacker
• Malware Attacker
 HTTP Content Rendering URL

• URL is an acronym for Uniform Resource Locator and is a reference (an

address) to a resource on the Internet protocol identifier: For the URL http://
example.com , the protocol identifier is http . Resource name:
• For the URL “http://example.com” , the resource name is example.com Http
Request
• HTTP Request is a packet of Information that one computer sends to
another computer to communicate something. To its core, HTTP Request is
a packet of binary data sent by the Client to server. An HTTP Request
contains following parts
1. Request Line
2. Headers, 0 or more Headers in the request
3. An optional Body of the Request
 -Continue

• HTTP Response is the packet of information sent by Server to the Client in

response to an earlier Request made by Client. HTTP Response contains
the information requested by the Client. For example, the request to
Weather Web Service made in the HTTP Request tutorial will contain the
weather details of the location.
• Just like HTTP Request, HTTP Response also has the same structure:
 ∙Status Line
 ∙ eaders, 0 or more Headers in the request
 ∙ n optional Body of the Request
 --Continue

When a web page is loaded, the browser creates

a Document Object Model of the page.
 ---Continue
• Browser object Model(BOM) : BOM provides you with a window objects, for
example, to show the width and height of the window. It also includes the
window. screen object to show the width and height of the screen.
 Cookies Frame and Frame Busting
• HTTP PROTOCOL: This is a stateless transport protocol in communication between client
and server. It means no state is stored during the period of communication. To
maintained session between client and server we use client side cookies
• Client side cookies (Header, cookies and request):
• An HTTP cookie (also called web cookie, Internet cookie, browser cookie,
or simply cookie) is a small piece of data sent from a website and stored on the
user's computer by the user's web browser while the user is browsing. Cookies were
designed to be a reliable mechanism for websites to remember stateful information (such
as items added in the shopping cart in an online store) or to record the user's browsing
activity (including clicking particular buttons, logging in, or recording which pages were
visited
• in the past). They can also be used to remember arbitrary pieces of information that
the user previously entered into form fields such as names, addresses, passwords, and
credit card numbers.
• Cookies authentication: A server and client can be recognized with the help of cookies
sending through authenticate server.
 Frame Bursting code

• Clickjacking allows an attacker to trick your users into clicking parts of your interface without their
consent.
• A simple way to describe this is, an attacker will embed your application in their site as an iframe.
• On top of the iframe they can show a completely different interface.
• You‟re thinking you‟re clicking buttons on your own interface, while in fact you are hitting the
„Delete my account‟ button in for example GMail.
• Because this technique completely operates with frames, it can be circumvented by using a
„Frame busting‟ technique. As a bonus, this will also disallow for example Digg to steal and
monetize your content.
• Frame busting can be achieved with a simple javascript technique: <script type=”text/javascript”>
• If(top !==self) top.location.replace(self.location.href); </script>
 SQLi(Structured Query Language Injection) Attack

• SQL is a query language that was designed to manage data stored in

relational databases.
• You can use it to access, modify, and delete data. Many web applications
and websites store all the data in SQL databases.
• In some cases, you can also use SQL commands to run operating system
commands.
• Therefore, a successful SQL Injection attack can have very serious
consequences. to find the
 --Continue

• Attackers can use SQL Injections to find the credentials of other users in the database. They can
then impersonate these users. The impersonated user may be a database administrator with all
database privileges.
• SQL lets you select and output data from the database. An SQL Injection vulnerability could allow
the attacker to gain complete access to all data in a database server.
• SQL also lets you alter data in a database and add new data. For example, in a financial
application, an attacker could use SQL Injection to alter balances, void transactions, or transfer
money to their account.
• You can use SQL to delete records from a database, even drop tables. Even if the administrator
makes database backups, deletion of data could affect application availability until the database
is restored. Also, backups may not cover the most recent data.
• In some database servers, you can access the operating system using the database server. This
may be intentional or accidental. In such case, an attacker could use an SQL Injection as the initial
vector and then attack the internal network behind a firewall.
 How to Prevent SQLi

Step 1: Train and maintain awareness

To keep your web application safe, everyone involved in building the web application
must be aware of the risks associated with SQL Injections. You should provide suitable
security training to all your developers, QA staff, DevOps, and SysAdmins. You can start
by referring them to this page.

Step 2: Don’t trust any user input

Treat all user input as untrusted. Any user input that is used in an SQL query introduces a
risk of an SQL Injection. Treat input from authenticated and/or internal users the same
way that you treat public input.

Step 3: Use whitelists, not blacklists

Don’t filter user input based on blacklists. A clever attacker will almost always find a way
to circumvent your blacklist. If possible, verify and filter user input using strict whitelists
only.
 --Continue

Step 4: Adopt the latest technologies

Older web development technologies don’t have SQLi protection. Use the latest version of
the development environment and language and the latest technologies associated with
that environment/language. For example, in PHP use PDO instead of MySQLi

Step 5: Employ verified mechanisms

Don’t try to build SQLi protection from scratch. Most modern development technologies
can offer you mechanisms to protect against SQLi. Use such mechanisms instead of
trying to reinvent the wheel. For example, use parameterized queries or stored procedures.

Step 6: Scan regularly (with Acunetix)

SQL Injections may be introduced by your developers or through external libraries/

modules/software. You should regularly scan your web applications using a web
vulnerability scanner such as Acunetix. If you use Jenkins, you should install the Acunetix
plugin to automatically scan every build
 Cross-Site Request Forgery(XSRF) Attack
• Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute

unwanted actions on a web application in which they are currently authenticated.

• With a little help of social engineering (such as sending a link via email or chat), an

attacker may trick the users of a web application into executing actions of the attacker’s

choosing.

• If the victim is a normal user, a successful CSRF attack can force the user to perform

state changing requests like transferring funds, changing their email address, and so
forth.

• If the victim is an administrative account, CSRF can compromise the entire web
application.

• This attack is also known as one-click attack or session riding

 Detection of XSS

• The most practicable makers that help in the timely detection of CSRF are:
 Websites allowing session management through GET requests. Third-
parties can get easy access to such sites. So, they are more prone to CSRF
attacks. Make sure your site is not among them.
 Web Proxies are very helpful in CSRF detection. As it keeps track of HTTP
requests’ journey from beginning to end, you can replay requests without
initiating an interaction with the client-side interface of the app.
 Prevention of XSRF
• CSRF-token-based prevention

CSRF tokens can be utilized by website owners or administrators for it. The
app security team should figure out the attack-prone part of server-side

functions and introduce the CSRF token in the HTML form of that vulnerable
operational part. Make sure that the intended HTML form is not a
component of session cookies. Also, utilize a cryptographically secured

random number generator for token-creation.

 --Continue
• Utilizing the SameSite Cookie Attribute

 It is generally used for supporting CSRF attack prevention methodology greatly.

Sharing a lot in common with Secure Flag and HTTPOnly, it equips the browser
adequately for handling the cookies as well as cross-site requests at once.

 Its acceptable values are as enlisted:

 A ‘Strict’ value will stop cookies transfer by browsing.

 ‘Lax’ is the default value that maintains security for web solutions when they

wish to allow user-access requests composed of external links. Presently, most

browsers have this feature as an added line of defense against CSRF attacks

while using the CSRF token alongside.

 The value ‘none’ is used you want to use cookies for accessing cross-site URLs.
 --Continue
• Utilizing user interaction for CSRF protection

It is the easiest way to implement a CSRF prevention strategy. It involves the use of re-
authentication, one-time token creation, and CAPTCHA deployment. All these techniques increase
user interaction and leave less scope for threat attacks to barge in. Also, it enhances the user
experience.
• Controlling Login CSRF

One can prevent CSRF from impacting the login forms by generating pre-sessions for each user and
introducing CSRF tokens in those sessions. It makes the early authentication safe. But, ensure
that this pre-session should be destroyed once the real session is initiated. Ignoring this will give
invitation to the session-fixation attack.

• Double submit cookies

It involves storing the similar token values in a cookie rather than a server session. Doing so
encourages the cookie-like CSRF token forwarding while associating a hidden field/value with it.
Upon receiving a request, the server needs to figure out whether the CSRF value, stored in hidden
fields and cookies, matches.
 XSS (Cross-Site Scripting )Attack

• Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious

scripts are injected into otherwise benign and trusted websites.
• XSS attacks occur when an attacker uses a web application to send
malicious code, generally in the form of a browser side script, to a different
end user.
• Flaws that allow these attacks to succeed are quite widespread and occur
anywhere a web application uses input from a user within the output it
generates without validating or encoding it.
 How to Prevent XSS
• Keep Software Up-To-Date

Regularly updating software will greatly reduce the vulnerabilities that leave a site or
application open to XSS vulnerabilities. You should also audit all of your applications
to determine which you need and which you rarely use.
• Sanitize And Validate Input Fields

Input fields are the most common point of entry for XSS attack scripts. Therefore,
you should always screen and validate any information input into data fields. This
is particularly important if the data will be included as HTML output to protect
against reflected XSS attacks.

Validation should occur on both the client-side and server-side as an added

precaution. validating the data before it’s sent to servers will also protect against
persistent XSS scripts. This can be accomplished using Javascript.
 How to Prevent XSS
• Web Application Firewall

A Web Application Firewall(WAF) can be a powerful tool for protecting against XSS
attacks. WAFs can filter bots and other malicious activity that may indicate an attack.
Attacks can then be blocked before any script is executed.
• Content Security Policy

A content security policy (CSP) can define the functions a website is allowed to
perform. They can be used to prevent a website from accepting any in-line scripts.
This may be the strongest method at your disposal as it can completely block XSS
attacks or at least greatly reduce the possibility of them.