Week 5

Question 1

describe the ssl handshake

Answer 1

1 client sends list of algorithms it supports, along with client nonce
2 server chooses algorithms from list; sends back choice + certificate +
server nonce
3 client verifies certificate, extracts server’s public key, generates
pre master secret, encrypts with server’s public key and sends to
server
4 client and server independently compute encryption and MAC keys
from pre master secret and nonces
5 client sends a MAC of all the handshake messages
6 server sends a MAC of all the handshake messages

Question 2

how might an attacker use http? how should we defend against this

Answer 2

Forms allow users to pass parameters to web pages. These are usually
internally passed as GET and POST requests.
Get parameters are contained in the request URL.
Post are contained in the HTTP packet header.
On the client side HTML (or Javascript) should check values before a
request is sent.
On the server side Ruby or Perl or another script language should check
values received.

Question 3

how can a cache/proxy be a weakness?

Answer 3

If a user sets all HTTP requests directly to the cache then the network
consumption is reduced, the response is faster and the original server is
freed up for other processing.
A cache can be poisoned when malicious, or wrong, information or links
are put into the cache. This is usually done by HTTP response splitting

Question 4

what is the 5 steps of a web service assesment atk?

Answer 4

Essentially this is a five step process:
1 Identify the web service running – look at HTTP head or use
WebServerFP or hmap type tools
2 Identify subsystems and enabled components (extensions, verified and
unverified components) such as ASP.NET, Frontpage, PHP,
OpenSSL, IIS ISAPI extensions.
3 Investigate known vulnerabilities in web services – MITRE, CVE,
metasploit tools etc for lists or tools such as N-Stealth, nkito (Linux)
4 Identify poorly constructed or protected sensitive data – poor HTTP
authentication, URL query strings
5 Assess CGI, ASP etc scripts – look for parm manipulation, filter
evasion, patch regularly. Some assessment tools are available such as
Achilles, Exodus, WebSleuth.

Question 5

what are security issues for databases

Answer 5

Not surprisingly access control, authentication, relaibility, data integrity are
all issues for database securities:
Access Control: restriction levels of read, write (update). Delete must
be at admin level.
Authentication: Pre phase of authentication needed for access.
Physical DB integrity: power failures, disc failure etc should not affect
the data
Logical DB integrity: The structure of the DB is preserved after data
modification (no loss of fields, keys etc).
Auditability: for forensic or legal reasons as well as reconstruction.
Two phase update: designed to prevent problems during update (long
intent phase and then commit phase when commit flag is set)

Question 6

how to prevent inference on databases?

Answer 6

Data could be partitioned - at a cost of redundancy, access efficiency
etc.
Data or tuples could be encrypted.
An integrity code could be applied to each cell (colour or level
coded). Sometimes called an Integrity Lock.
A sensitivity lock could be applied - a different lock for each record
which indicates the sensitivity level, e.g. an encryption based on
record number and sensitivity level so that an attacker can not infer
much from two records with the same sensitivity level.