UNIT-3:- Secure Architecture Principles Isolation and leas:

Access Control Concepts- Access control is a security technique that

regulates who or what can view or use resources in a computing
environment. It is a fundamental concept in security that minimizes risk
to the business or organization. Logical access control limits connections
to computer networks, system files and data.
Various access control examples can be found in the security systems in
our doors, key locks, fences, biometric systems, motion detectors, badge
system, and so forth.
Three main types of access control systems are: Discretionary Access
Control (DAC), Role Based Access Control (RBAC), and Mandatory
Access Control (MAC).
The purpose of an access control system is to provide quick, convenient
access to those persons who are authorized, while at the same time,
restricting access to unauthorized people. The access card may be
thought of as an electronic "key".
Unix and windows access control summary-
UNIX -- Access Control-

UNIX uses access control lists. A user logs into UNIX and has a right to start
processes that make requests. A process is "bigger" than a subject, many domains
may correspond to a single process. Each process has an identity(uid). This uid is
obtained from the file that stores user passwords: /etc/passwd. An entry in
/etc/passwd may look like:

Every process inherits its uid based on which user starts the process. Every process
also has an effective uid, also a number, which may be different from the uid.

Finally, each UNIX process is a member of some groups. In the original UNIX
every user was a member of one group. Currently, users can be members of more
than one group. Group information can be gotten from /etc/passwd or from a file
/etc/groups. System administrators control the latter file. An entry in /etc/groups
may look like:
When a process is created, associated with it is the list of all the groups it is in.

Recall that groups are a way to shorten access control lists. They are useful in other
ways as well.

All of the above implements a form of authentication, knowing the identity of the
subject running command. Objects in UNIX are files. UNIX attempts to make
everything look like a file. (E.g., one can think of "writing" to a process as
equivalent to sending a message, etc.) Because of this, we will only worry about
files, recognizing that just about every resource can be cast as a file.

Here is a high-level overview of the UNIX file system. A directory is a list of

pairs: (filename, i-node number). Running the command 'ls' will produce a list of
filenames from this list of pairs for the current working directory. An i-node
contains a lot of information, including:

where the file is stored -- necessary since the directory entry is used to access the
file,

the length of the file -- necessary to avoid reading past the end of the file,

the last time the file was read,

the last time the file was written,

the last time the i-node was read,

the last time the i-node was written,

the owner -- a uid, generally the uid of the process that created the file,

a group -- gid of the process that created the file is a member of,

12 mode bits to encode protection privileges -- equivalent to encoding a set of

access rights.
How access control in UNIX is different from Windows?

NTFS has Windows ACEs. Unix uses "mode bits" on each file. On NTFS, each
file can have an owner, and zero or more Windows access control entries (ACEs).
An ACE consists of a principal (users and groups are principals), a set of
operations (Read, Write, Execute, etc.)

Windows NT -- Access Control-

Windows NT supports multiple file systems, but the protection issues we will
consider are only associated with one: NTFS. In NT there is the notion of an item,
which can be a file or a directory. Each item has an owner. An owner is usually the
thing that created the item. It can change the access control list, allow other
accounts to change the access control list and allow other accounts to become
owner. Entries in the ACL are individuals and groups. Note that NT was designed
for groups of machines on a network, thus, a distinction is made between local
groups (defined on a particular workstation) and global groups (domain wide). A
single name can therefore mean multiple things.

NTFS is structured so that a file is a set of properties, the contents of the file being
just one of those properties. An ACL is a property of an item. The ACL itself is a
list of entries: (user or group, permissions). NTFS permissions are closer to
extended permissions in UNIX than to the 9 mode bits. The permission offer a rich
set of possibilities:

R -- read

W -- write

X -- execute

D -- delete

P -- modify the ACL

O -- make current account the new owner ("take ownership")

The owner is allowed to change the ACL. A user with permission P can also
change the ACL. A user with permission O can take ownership. There is also a
packaging of privileges known as permissions sets:
no access

read -- RX

change -- RWXO

full control -- RWXDPO

NT access control is richer than UNIX, but not fundamentally different.

Common Issues with Access Control Systems-

If you’re a business that requires a high level of security to control your physical or
digital assets, you need an access control system. Access control systems allow
businesses to verify the identity of a person before they are allowed access to a
physical or digital space. But as with all technology, problems can arise during use.

What are some common issues that businesses have with access control systems?

1. Not Secure Enough

2. Keycards Lack True Authorization

3. Improper Setup

4. Inefficient Management

Even though issues can happen, your company can avoid running into problems
with your access control system by maintaining the system regularly and working
with a consultant on the system setup. With your access control system working
optimally, you can have peace of mind that your business’s assets are safe and
secure.

Browser isolation- Browser Isolation (also known as Web Isolation) is a

technology that contains web browsing activity inside an isolated environment, like
a sandbox or virtual machine, in order to protect computers from any malware the
user may encounter. This isolation may occur locally on the computer or remotely
on a server.
Browser isolation is a cyber-security model which aims to physically isolate an
internet user's browsing activity away from their local networks and infrastructure.

WEB Security-
What is the web?

• A collection of application-layer

services used to distribute content

– Web content (HTML)

– Multimedia

– Email

– Instant messaging

• Many applications

– News outlets, entertainment, education, research and technology.

– Commercial, consumer and B2B

• The largest distributed system in existence

– threats are as diverse as applications and users

– But need to be thought out carefully …

Secure socket Layer (SSL/TLS)

• Used to authenticate servers

– Uses certificates, “root” CAs

• Can authenticate clients

• Inclusive security protocol

• Security at the socket layer

– Transport Layer Security (TLS)

– Provides

• authentication

• confidentiality

• integrity.

1. HTTP, HTML, and JavaScript

• HTTP Request

– Request line, such as GET /images/logo.gif HTTP/1.1, which requests a

resource called /im- ages/logo.gif from server

– Headers, such as Accept-Language: en

– An empty line

– An optional message body

• Request methods
– GET Request: attach the data in the URL

– POST Request: Submits data to be processed (e.g., from an HTML form) to

the identified resource. The data is included in the body of the request.

• HTML: An Example

• JavaScript in HTML: A “Hello World” Example

• What can JavaScript do?

– JavaScript gives HTML designers a programming tool.

– JavaScript can put dynamic text into an HTML page: A JavaScript statement
like the following, which write a variable text into an HTML page:

document. write("<h1>" + name + "</h1>")

– JavaScript can interact with the server (e.g. using Ajax).

Ajax: Ajax (shorthand for asynchronous JavaScript + XML) is a group of

interrelated web devel- opment techniques used on the client-side to create
interactive web applications. With Ajax, web applications can retrieve data from
the server asynchronously in the background without interfering with the display
and behavior of the existing page. The use of Ajax techniques has led to an
increase in interactive or dynamic interfaces on web pages and better quality of
Web services due to the asyn- chronous mode. Data is usually retrieved using the
XMLHttpRequest object. Despite the name, the use of JavaScript and XML is not
actually required, nor do the requests need to be asynchronous.

• Secure Web Access

– Authentication

– Access Control: what is the basis of access control?

– Discussion
Difference between Web Access Control and OS Access Control

OS is stateful. After an user is authenticated, it is remembered until the user logs

out. The OS keeps the state: the authenticated user gets a process with his/her
privileges; this process keeps the fact that the user is authenticated. Other users
cannot hijack this process.

Web server is stateless. When a user is authenticated, he/she may send several
other requests. The entire duration is called a session. Since web server is stateless,
it does not remember anything about this session. Namely, when the user sends a
request, the server does not know whether they are from the same session (hence,
from the same user). To put in another perspec- tive, because of the lack of session
concept at web server, each web request has to be authenti- cated; otherwise,
attackers can hijack a session.

• Session ID

Web applications have to remember sessions. For example, when a host needs to
customize the content of a website for a user, the web application must be written
to track the user’s progress from page to page.

How to know two requests are from the same sessions, hence do not need
seperate authentication?

– One common solution is to use session ID.

– Where is session ID stored

∗ Using cookies to record states: will be included automatically in the HTTP

request.

∗ Using hidden variables in forms: will be sent automatically when the form is
submitted.

Using URL encoded parameters: has to attach the session ID in the HTTP request.
Here is an example:

/index.php?session_id=some_unique_session_code.
• Cookies and Session ID

– A cookie (also tracking cookie, browser cookie, and HTTP cookie) is a

small piece of text stored on a user’s computer by a web browser. A cookie
consists of one or more name-value pairs containing bits of information such as
user preferences, shopping cart contents, the identifier for a server-based session,
or other data used by websites.

– It is sent as an HTTP header by a web server to a web browser and then sent
back unchanged by the browser each time it accesses that server. A cookie can be
used for authenticating, session tracking (state maintenance), and remembering
specific information about users, such as site preferences or the contents of their
electronic shopping carts. The term ”cookie” is derived from ”magic cookie”, a
well-known concept in UNIX computing which inspired both the idea and the
name of browser cookies. Some alternatives to cookies exist; each has its own
uses, advantages, and drawbacks.

– Being simple pieces of text, cookies are not executable. They are neither
spyware or viruses, although cookies from certain sites are detected by many anti-
spyware products because they can allow users to be tracked when they visit
various sites.

• Server-Side Access Control

– Subject: authentication with session id.

– Objects: files, data, etc.

– Policy: can be DAC (e.g. Facebook), MAC or others.

• Browser-Side Access Control

– The server-side access control relies on the integrity of the browser-side

access control.

– The integrity of user’s behavior should also be preserved: i.e., malicious

users cannot affect/change a legitimate users’s behavior.
– What are the essential requirements?

∗ Session id: cannot be stolen.

∗ Program/Data: cannot be modified by unauthorized users.

– Policy: Same Origin Policy (SOP)

2. Access Control on JavaScript

Where do we start? We need to understand what are subject and object first, then
we can talk about the access control.

• Subject (fine granularity): The origin of JavaScript code.

Objects (fine graularity): DOM, Cookies, Operating System Resources (files,

processes, devices, networks, keyboard, mouse, memory, etc).

• Policies:

– Same Origin Policy (SOP).

– Directly accessing of the OS resources are prohibited.

– Browsers provide APIs to JavaScript, so OS resources can be indirectly

accessed. For example, JavaScript can send out messages using Ajax APIs, access
DOM objects and cookies using DOM APIs, and so on.

3 Cross-Site Scripting (XSS) Attack-

• Objective of XSS:

– Attacker injects malicious JavaScript code to the target web site X.

– When other users browse the infected pages from X, the browser believes
that the JavaScript is from X.

– The Same Origin Policy allows the malicious JavaScript to access cookies of
X, which can send legitimate HTTP requests to X onbehalf of the users, without
the users’ concent.
• Samy worms (see the narrative from Samy at http://namb.la/popular/).

– Myspace.com: Samy add JavaScript code in his profile; whoever browses

the profile will get infected.

– The worm added Samy to the victim’s friend list, and then further propogate
the worms to those who view their profiles.

– Samy become a friend of one million users in less than 20 hours.

• Potential Damage

– Sending unauthorized requests on behalf of the victims.

– Web defacing: the malicous JavaScript code can access and modify the
DOM objects within the page. For example, it can replace a picture in the web
page with a different picture.

• Countermeasures

– Do a better filtering (proven difficult).

– Noscript region: Do not allow JavaScript to appear in certain region of a web

page.

4 Cross-Site Request Forgery (CSRF) Attack-

• CSRF Attack

– Web application tasks are usually linked to specific urls (Example:

http://site/buy_ stocks?buy=200&stock=yahoo) allowing specific actions to be
performed when requested.

– If a user is logged into the site and an attacker tricks their browser into
making a request to one of these task urls, then the task is performed and logged as
the logged in user. The tricks can be placed on a web page from the attacker; all
the attacker needs to do is to trick the user to visit their attacking web page while
being logged into the targeted site.
– When the request is made by the user (whether the user is tricked or not), the
cookie will be attached to the request automatically by browsers.

– For web applications using HTTP GET: attacker can use image tag <img> to
cause the victim’s browser to send out a HTTP GET request (when the victim
visits the attacker’s web page, the HTTP GET request will be initiated by the
image tag. Here is an example:

<img src="http://site/buy_stocks?buy=200&stock=yahoo">

– For web applications using HTTP POST: sending data to such applications
is not as easy as sending data to a GET-based applications, because we cannot
append the data to the end of URL for POST-based applications. However, with
the help of JavaScript, attackers can send the data. The basic idea is for the attacker
to craft a web form on his/her site (using JavaScript), and then use JavaScript to
automatically submit the form to the target site.

We cannot use AJAX here, because AJAX can only talk back to the source of the
web page (SOP policy).

• Difference between CSRF and XSS-

– CSRF does not need to run JavaScript code (for GET only); XSS does.

– Using JavaScript code:

∗ CSRF: the code runs directly from the attacker’s web page.

∗ XSS: the code has to be injected to the target web site’s page.

– Server-side input validation:

∗ It does not prevent CSRF, because the attacking contents are not on the target
web site.

∗ It can prevent XSS to certain degree, if the malicious JavaScript code can be
filtered out.
• Countermeasures

– Because the JavaScript code used (if used) by CSRF does not come from the
target web site, the malicious JavaScript cannot see the cookies from the target
web site.

– We can require that all the HTTP request (both GET and POST) to also
include something from the cookie (such as the session ID) in the attached
parameters, in addition to the cookies that are already attached automatically by the
browser. JavaScript code from the target web site can get the secret from the
cookie, but the JavaScript code from the malicious web site cannot access the
cookies.

5. Fundamental Problems of XSS and CSRF-

What is the fundamental problem of XSS and CSRF? Let us evaluate these
problems from the access control perspective. Is there anything wrong with the
access control model currently used by web browser (i.e. the SOP model)? If not,
can we pinpoint what has gone wrong from the design perspective?

Let us review the principles of access control formuated by Saltzer and Schroeder
in their classical paper titled The Protection of Information in Computer Systems .
We have covered these principles in our access control lectures. Here we will
evaluate an access control design using these principles:

• Economy of mechanism

• Fail-safe defaults

• Complete mediation

• Open design

• Separation of privilege

• Least privilege
• Least common mechanism

• Least common mechanism

• Psychological acceptability.

Virtually all businesses, most government agencies, and many individuals now
have Web sites. The number of individuals and companies with Internet access is
expanding rapidly and all of these have graphical Web browsers. As a result,
businesses are enthusiastic about setting up facilities on the Web for electronic
commerce. But the reality is that the Internet and the Web are extremely vulnerable
to compromises of various sorts. As businesses wake up to this reality, the demand
for secure Web services grows.

The topic of Web security is a Very broad one. In this chapter, we begin with a
discussion of the general requirements for Web security and then focus on two
standardized schemes that are becoming increasingly important as part of Web
commerce: SSL/TLS and SET.

Web Security Considerations:

The World Wide Web is fundamentally a client/server application running over the
Internet and TCP/IP intranets. As such, the security tools and approaches discussed
so far in this book are relevant to the issue of Web security. But, the Web presents
new challenges not generally appreciated in the context of computer and network
security:

• The Internet is two way. Unlike traditional publishing environments, even

electronic publishing systems involving teletext, voice response, or fax-back, the
Web is vulnerable to attacks on the Web servers over the Internet.

• The Web is increasingly serving as a highly visible outlet for corporate and
product information and as the platform for business transactions. Reputations can
be damaged and money can be lost if the Web servers are subverted.
• Although Web browsers are very easy to use, Web servers are relatively
easy to configure and manage, and Web content is increasingly easy to develop,
the underlying software is extraordinarily complex. This complex software may
hide many potential security flaws. The short history of the Web is filled with
examples of new and upgraded systems, properly installed, that are vulnerable to a
variety of security attacks.

• A Web server can be exploited as a launching pad into the corporation's or

agency's entire computer complex. Once the Web server is subverted, an attacker
may be able to gain access to data and systems not part of the Web itself but
connected to the server at the local site.

• Casual and untrained (in security matters) users are common clients for
Web-based services. Such users are not necessarily aware of the security risks that
exist and do not have the tools or knowledge to take effective countermeasures.

Web Security Threats:

Provides a summary of the types of security threats faced in using the Web. One
way to group these threats is in terms of passive and active attacks. Passive attacks
include eavesdropping on network traffic between browser and server and gaining
access to information on a Web site that is supposed to be restricted. Active attacks
include impersonating another user, altering messages in transit between client and
server, and altering information on a Web site.

A Comparison of Threats on the Web

Threats

Integrity-Modification of user data Trojan horse browser Modification of memory

Modification of message traffic in transit.

Confidentiality-Eavesdropping on the Net Theft of info from server Theft of data

from client Info about network configuration Info about which client talks to
server. .
Denial of Service- Killing of user threads Flooding machine with bogus requests
Filling up disk or memory Isolating machine by DNS attacks .

Authentication- Impersonation of legitimate users Data forgery.

Secure development- Secure Development Lifecycle (SDL) is the process of

including security artifacts in the Software Development Lifecycle (SDLC).
SDLC, in turn, consists of a detailed plan that defines the process organizations use
to build an application from inception until decommission. Planning and
requirements.

Why is secure development important?

The most important reasons to adopt SDL practices are: Higher security. In SDL,
continuous monitoring for vulnerabilities results in better application quality and
mitigation of business risks. Cost reduction.