1. COMP1321 Digital Infrastructures
Richard Henson
University of Worcester
March 2018

2. Week 20 Communications: Securing Web Pages
Objectives:
Explain how HTTP is not a secure protocol
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

3. Vulnerabilities of Networks
When the world wide web became popular…
all organisations expected to have a web presence
normal to use http as the protocol
by default, “anonymous” login
no authentication or encryption on web pages
HMTL forms sent using http vulnerable to attack

4. Development of https
Web pages just providing information have no need of security
http fine for businesses using web pages for “push” marketing purposes
different matter when user expected to input data…
HTTPs protocol developed (circa 1996) by Netscape, to drive e-commerce

5. Secure Sockets Layer (SSL) and Secure HTTP
Summary of SSL:
devised by Netscape to work with HTTP-S to only display the web page in a secure environment
very successful
never been cracked
further developed by IETF into TLS v2
But how do the protocols fit together?

6. Back to the TCP/IP model
Zoom in on TCP and the upper layers…
TELNET
FTP
SMTP
http-s
HTTP
Level 7
Session layer authentication protocols: e.g. SSL
Level 5
TCP/TLS
Level 4

7. Secure HTTP (https) and the session layer
Web Applications
use layer protocols to 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

8. “Sockets”, Secure Sockets and the Session Layer
In the early days of Unix, someone devised the concept of a logical “socket” between transport layer and application layer:
each application uses a protocol that TCP could plug in to with the help of a TCP port
network authentication between application and user could be handled by the “socket”

9. OSI and Sockets
The sockets concept continued, and became part of the OSI seven layer model
assimilated into the session layer/transport layer interface
When Microsoft developed their own version of TCP/IP to interface with Windows and enabled browsers to work, the level 4/5 interface software became WINSOCK

10. 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!

11. Secure HTTP and the user authentication problem
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
application
authentication
required
transport

12. SSL and PKI PKI = public key infrastructure
the software used to enable authentication and encryption of data to be sent through the Internet
SSL integrated with PKI from the start
client-server with server-end having to authenticate itself to the client
uses a server ceertificate
if satisfied, web page encrypted, sent, decrypted, then displayed

13. Computer Authentication
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

14. 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 also ensures that it is:
encrypted before being sent
decrypted upon receipt and prior to processing for display

15. 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

16. 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

17. 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

18. 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”

19. 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

20. 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

21. 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.
rather than
Until the user does use https they will get an error, rather than the pop up that proceeds the secure web page

22. 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

23. 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 instead of
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

24. 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:
will appear before the URL
“lock” symbol appears on the bottom left of the screen

25. 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

26. CWE Top 25 faults (1)
Rank ID
Name 1
CWE-79
Failure to Preserve Web Page Structure ('Cross-site Scripting') 2
CWE-89
Improper Sanitization of Special Elements used in an SQL Command ('SQL Injection') 3
CWE-120
Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') 4
CWE-352
Cross-Site Request Forgery (CSRF) 5
CWE-285
Improper Access Control (Authorization) 6
CWE-807
Reliance on Untrusted Inputs in a Security Decision 7
CWE-22
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') 8
CWE-434
Unrestricted Upload of File with Dangerous Type 9
CWE-78
Improper Sanitization of Special Elements used in an OS Command ('OS Command Injection') 10
CWE-311
Missing Encryption of Sensitive Data 11
CWE-798
Use of Hard-coded Credentials 12
CWE-805
Buffer Access with Incorrect Length Value 13
CWE-98
Improper Control of Filename for Include/Require Statement in PHP Program ('PHP File Inclusion')
[TSI/2012/183]
© Copyright

27. CWE Top 25 faults (2) 14 CWE-129 Improper Validation of Array Index 15
Rank ID
Name 14
CWE-129
Improper Validation of Array Index 15
CWE-754
Improper Check for Unusual or Exceptional Conditions 16
CWE-209
Information Exposure Through an Error Message 17
CWE-190
Integer Overflow or Wraparound 18
CWE-131
Incorrect Calculation of Buffer Size 19
CWE-306
Missing Authentication for Critical Function 20
CWE-494
Download of Code Without Integrity Check 21
CWE-732
Incorrect Permission Assignment for Critical Resource 22
CWE-770
Allocation of Resources Without Limits or Throttling 23
CWE-601
URL Redirection to Untrusted Site ('Open Redirect') 24
CWE-327
Use of a Broken or Risky Cryptographic Algorithm 25
CWE-362
Race Condition
[TSI/2012/183]
© Copyright

28. Thanks for Listening 