Transcript what are the three "core/key skills"?

COMP1321
Digital Infrastructures
Richard Henson
University of Worcester
April 2013
Week 19 Communications:
Securing Web Pages

Objectives:
Explain how HTTPS/SSL/TLS fits into the
OSI seven layer model
Take the necessary steps to implement an
SSL system on a www server that uses
EAP/TLS
Apply PKI principles to produce a workable
for protecting web pages at the client end
Secure Sockets Layer and
Secure HTTP

Summary of SSL:
devised by Netscape
very successful
works with HTTP-S to only display the web
page in a secure environment
never been cracked
Further developed by IETF

But how does it all fit together?
Back to the TCP/IP model

Zoom in on TCP and the upper layers…
TELNET
FTP
SMTP
http-s
HTTP
Level 7
Session layer protocols: eg Unix “sockets”, SSL
Level 5
Level 4
TCP/TLS
Secure HTTP (https)
and the session layer


All application layer protocols communicate
with TCP layer through unique TCP ports and
(optional) session layer logon
Security can also be imposed, therefore, by
authenticating at the “logon” layer
 e.g. using Kerberos authentication
 username/password is required before data can
pass the session layer and be displayed by the
browser
Secure Sockets and the
Session Layer

In the early days of Unix, someone devised
the concept of a “socket”:
 a protocol between application and transport
layers that TCP could plug in to with the help of a
TCP port
 network authentication could be handled by the
“socket”


The concept continued, and was assimilated
into the session layer
When Windows interfaced with TCP/IP for the
first time, the term WINSOCK was introduced
The trouble with HTTP


General Internet principle of “anyone can go
anywhere”
On a Windows system with www access:
 TCP can link to HTTP through “Winsock”
 session layer authentication not invoked
 HTML data transferred directly to the presentation
and application layers for display

Problem:
 the data is visible to anyone else on the Internet
who may have access to that machine and the
data path to it!
Secure HTTP and the user
authentication problem

application
authentication
required
transport

Makes use of the
potential for requiring
authentication at the
session layer
SSL protocol can require
a username/password
combination before data
passes through the
socket from transport
layer to application layer
Computer Authentication


SSL is able to use the PKI (remember that?)
When a user first attempts to communicate
with a web server over a secure connection:
 that server will present the web browser with
authentication data
 presented as a server certificate (remember
those?)
» verifies that the server is who and what it claims to be

Works both ways…
 protocol: EAP/TLS
 server may in return request client authentication
via username/password
SSL and Encryption

Authenticating the user & server only
helps when the data is at its at its source
or destination
data also needs to be protected in transit…

SSL working at level 5/6 also ensures
that it is:
» encrypted before being sent
» decrypted upon receipt and prior to processing
for display
Confidentiality & Integrity

Encryption of SSL responses can be
Either Standard 40 bit RSA
» difficult to break confidentiality
Or Secure 128 bit RSA
» virtually impossible to “crack”

Guarantee that the data will not be
modified in transit by a third party
integrity therefore also maintained
Is an SSL Digital Certificate
Really Necessary?

Yes:
 for sites involved in e-commerce and therefore
involving digital payment with authentication
 any other business transaction in which
authentication is important

No:
 if an administrator simply wants to ensure that
data being transmitted and received by the server
is private and cannot be snooped by anyone
eavesdropping on the connection
 In such cases, a self-signed certificate is
sufficient
The Web of Trust (PGP)
Based on individual trust networks built
up between individuals
 Possible to “self sign” a digital certificate

if someone trusts you, a self-signature may
be all they need
OpenPGP identiity certificates are designed
to be self-signed
Verisign Trust System

Web of Trust
OK for academics (“good” people?)
but bad” people can do business

Verisign system presented as an
alternative
developed so that people could trust
strangers in business transactions
financial institutions provide the “trust”
General Tips on
Running SSL

Secure websites…
 designed to be as efficient as securely possible
» problem: encryption/decryption is computationally
expensive from a performance standpoint
 not strictly necessary to run an entire Web
application over SSL
» customary for a developer to find out decide which pages
require a secure connection and which do not
» and create secure and non-secure folder structures for
the respective web pages
When to use SSL

Whenever web pages require a secure
connection with the server e.g.:
login pages
personal information pages
shopping cart checkouts
any pages where credit card information
could possibly be transmitted
Running HTTPS

A client-server service that runs on the Web
server (like http, smtp, and ftp)
 uniquely designed so it will not run on a server
without an installed and active server certificate

Once the service has been set up, https will
require users to establish an encrypted
channel with the server
 i.e. https://
 rather than http://

Until the user does use https they will get an
error, rather than the pop up that proceeds the
secure web page
Running HTTPS

Use of encryption can interfere with access to
data… (i.e. availability)
 an encrypted channel running https requires that the
user's Web browser and the Web server BOTH
support the same encryption scheme

For example:
 IF an IIS Web Server is set to use default secure
communication settings
 THEN the client Web browser must support a
session key strength of 40 bits, or greater
Accessing a Web Page
using HTTPS

If the client is to request a page that needs
SSL:
 in the HTML code that will call that page, prefix the
address with https:// instead of http://
» the system will do the rest…

Any pages which absolutely require a secure
connection need to:
 check the protocol type associated with the page
request
 take appropriate action if https: is not specified
Screen Prompts that a Web
Page has been delivered
securely using SSL

1. (depending on browser settings)
 pop up appears…
 informs the client that they are entering a secure
client-server connection
 must be acknowledged to continue

2. Web page displayed:
 https:// will appear before the URL
 “lock” symbol appears on the bottom left of the screen
How secure are
your mobile apps?

Possible vulnerabilities:
MITM attack (capture of code en route)
» Much easier on wireless networks
SQL injection
» unprotected data windows
» needs input validation controls
DOS & DDOS
» exploitation that invokes ping
CWE Top 25 faults (1)
Rank
ID
Name
1
CWE-79
2
CWE-89
3
CWE-120
4
5
6
7
CWE-352
CWE-285
CWE-807
CWE-22
8
9
CWE-434
CWE-78
10
11
12
13
CWE-311
CWE-798
CWE-805
CWE-98
Failure to Preserve Web Page Structure ('Cross-site
Scripting')
Improper Sanitization of Special Elements used in an
SQL Command ('SQL Injection')
Buffer Copy without Checking Size of Input ('Classic
Buffer Overflow')
Cross-Site Request Forgery (CSRF)
Improper Access Control (Authorization)
Reliance on Untrusted Inputs in a Security Decision
Improper Limitation of a Pathname to a Restricted
Directory ('Path Traversal')
Unrestricted Upload of File with Dangerous Type
Improper Sanitization of Special Elements used in an OS
Command ('OS Command Injection')
Missing Encryption of Sensitive Data
Use of Hard-coded Credentials
Buffer Access with Incorrect Length Value
Improper Control of Filename for Include/Require
Statement in PHP Program ('PHP File Inclusion') [TSI/2012/183]
© Copyright 2003-2012
CWE Top 25 faults (2)
Rank
ID
14
15
CWE-129 Improper Validation of Array Index
CWE-754 Improper Check for Unusual or Exceptional
Conditions
CWE-209 Information Exposure Through an Error Message
CWE-190 Integer Overflow or Wraparound
CWE-131 Incorrect Calculation of Buffer Size
CWE-306 Missing Authentication for Critical Function
CWE-494 Download of Code Without Integrity Check
CWE-732 Incorrect Permission Assignment for Critical
Resource
CWE-770 Allocation of Resources Without Limits or Throttling
CWE-601 URL Redirection to Untrusted Site ('Open Redirect')
CWE-327 Use of a Broken or Risky Cryptographic Algorithm
CWE-362 Race Condition
16
17
18
19
20
21
22
23
24
25
Name
[TSI/2012/183]
© Copyright 2003-2012
Thanks for Listening
