Transcript ppt - of Manish Mehta

Web Security
Manish Mehta
04/16/03
Web Security Problem

3 Primary Components
 Server-side
security
- Securing Web-server and data hosted
on it.
 Client-side security
- Securing end user’s computer.
(Browser specifically)
 Connection security
- Securing the connection between Client
and server and information exchanged.
User’s view of Security
The remote server is owned and operated
by the legitimate organization/person.
 The documents returned from the server
are free from dangerous viruses and
malicious contents.
 The remote server will not record or
distribute user’s private information without
user’s permission.

WebMaster’s view of security




No user can break-in to the system and alter the
contents of the web-site.
No user will get access to documents that she is
not privy to.
The user will not crash the server making it
unavailable to use. (DoS)
If the user has identified herself, she is what she
claims to be.
Both parties common view
Network connection is free from third party
eavesdroppers.
 The integrity of information exchanged is
preserved.

Risks


To the End user
- Active Contents ( Java Applets,
JavaScripts, ActiveX)
- Privacy Infringement (Cookies)
To the Website
- Webjacking (Server modules/CGI)
- Server/LAN break-ins
- DoS attacks (OS/CGI holes)
Risks (Contd.)

To Both the Parties
- Eavesdropping (sniffers)
- Fraud (PKI)
Connection Security
Cryptography reviewed
Symmetric Cryptography
- DES, 3DES, DESx, GDES, RDES
- RC2, RC4, RC5
- IDEA, Blowfish
 PKI (Asymmetric)
- RSA
- El Gamal

Message digest
Generally used to help check the integrity
of the data.
 Algorithms

- MD4 (Rivest)
- MD5 (Rivest)
- SHA (NIST)
Certificate Authorities



Certificate Authorities (CAs) are Trusted Third
Parties.
Root CA certificates are self-signed and are
provided with software by the vendors.
Certificate Chains
- Root CA can sign another CA’s public key
granting it signing authority.
- This starts certificate chain
- One can walk thru the chain until he reaches
the end-user certificate.
How to get a certificate?





Generate Public/Private key pair.
Send Public key and Integrity info. To CA
CA verifies your identity and will generate a
certificate with your public key and other
identity information.
CA generates message digest from the
certificate and signs the hash value with its
private key.
Now this certificate can be used to prove
your identity.
Certificate Expiration and
Revocation List
Certificates generally expire in 1 year.
 Revocation list has to be checked before
starting conversation for invalid certificates
(Revoked before expiration)
 Master Certificate Revocation List (CRL) is
impractical to maintain.

Internet Crypto Protocols
DNSSec - Secure DNS
 IPSec - Packet Level Encryption
 PCT – TCP/IP level encryption
 PGP – E-mail
 S/MIME – E-mail
 S-HTTP – web Browsing

Internet Crypto Protocols (Contd.)
Secure RPC – Remote Procedure Calls
 SET – Electronic funds
 SSL – TCP/IP level encryption
 SSH – Remote Login
 TLS – TCP/IP level Encryption

Roles of Cryptography
Authentication
 Authorization
 Confidentiality
 Integrity
 Non-repudiation

What Crypto Can’t do?







Protect unencrypted documents
Protect against stolen key
Protect against most DoS attacks
Protect against records of message traffic or the
fact that message was sent.
Protect against a booby-trapped encryption
program.
Protect against a traitor or a mistake.
Protect against a passerby.
Understanding Differences

S-HTTP v/s SSL
-

S-HTTP: Designed for web protocols only.
SSL: Any TCP/IP protocol can use.
SSL v/s IPSec
SSL: Change the existing software
User level authentication possible.
- IPSec: No need to change the existing s/w
Machine level authentication only.
-
http v/s https
HTTP – Unencrypted traffic (80)
 HTTPS – Uses SSL (443)

What all is encrypted in https
URL of the requested document.
 Contents of the requested document.
 Contents of any submitted fill-out forms.
 Cookies in both directions.
 Contents of HTTP header.

Client Side Security
SSL at work
Look for the icon and certificate.
 Browser Preferences

Internet Options  Advanced  security
 Netscape: Preferences  SSL
 IE:
Things to look for

Site name mismatch
 URL

Mixed pages
 In-line

insecure forms
Certificate Revocation and Expiration
 Browsers

generally don’t check CA’s CRL.
CA and site certificate
 Browsers
come with several CA public keys.
 These public keys are self signed.
Internet options  contents  publishers.
Types of certificates

CA certificate
 Self signed
 Sometimes

cross-certified.
Server certificate
 Contains
public key of the server, Name of the org.,
DNS name, …

Personal certificate
 Individual’s name, public key, e-mail, DOB, …
 Use : Bank account holder only case, S/MIME

Software publisher certificate
 To
verify signature on software (eg. winzip80.exe)
Active Contents
Not just HTML, ASP, PHP; plug-ins,
ActiveX, Visual Basic are also called
mobile codes.
 There are 2 categories

 User
runs the code ( I Love You worm)
 Browser runs it.
Helper Applications
They are external viewers.
 Real Audio, WMP (.asf, .asx)
 Any application can be used as helper
application.




command.com for .bat files?
PowerPoint can call external application.
Helper application will have its own
window.
Plug-ins
Generally third party codes.
 Run only in the context of Browser
Window.
 Manually Downloaded
 Eg. Macromedia Flash, Adobe
 Buggy plug-ins can ruin your day.

ActiveX Controls (.ocx)
Think of this as a self-installing plug-in.
 Comes in <OBJECT> tag in HTML.
 It can do ANYTHING ! (raw machine code)

Plug-ins v/s Controls
Plug-ins just extend Browser capability
and are installed manually.
 Controls

 Can
upgrade your OS
 Perform flash upgrade to ROM BIOS
 Providing conventional windows applications
within a “browser” interface.
 INSTALLED AUTOMATICALLY !!
The <OBJECT> Tag




Parameters can be specified for the controls.
Eg.
<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000“
codebase="http://macromedia.com/cabs/swflash.cab#version=4,0,0"
id="sidemenu" width="142" height="410">
<param name="movie" value="/sidemenu/sidemenu.swf">
<param name="quality" value="high">
<param name="bgcolor" value="#FFFFFF">
<embed name="sidemenu"
src="http://manishmehta.com/sidemenu.swf" quality="high"
bgcolor="#FFFFFF" width="142" height="410" type="application/xshockwave-flash"
pluginspage="http://www.macromedia.com/shockwave/download/ind
ex.cgi?P1_Prod_Version=ShockwaveFlash">
</embed></object>
Authenticode System




For authenticity of the downloaded code.
Requires “Software Publisher’s Certificate”
Defines standard for digitally signing windows
executables and .CAB files.
Authenticode signatures are checked by IE only
when control is downloaded from the network.
Downloaded controls are stored in a directory
whose contents are implicitly trusted.
Where does Authenticode fail?
If the ActiveX control contain malicious
code put there without the knowledge of
responsible signer.
 Coding vulnerabilities (Buffer Overflow)
 If you have people who don’t care if you
find them later.
 ActiveX control erasing its own signature
after starting execution, leaving no
record/proof.
 Forensics tasks are difficult to trace the
doer.

Real-life Examples

Internet Exploder
 An ActiveX
control
 Used a Personal Publisher Certificate
 10 Sec countdown and shutdown.

Chaos Computer Club (CCC), Germany
 Demo
only on TV.
 Searched for financial software “Quicken” on
the system and transferred sums to CCC a/c.
Flash and Shockwave

A bug found in 1997 could read files from
the hard disk of the client.
Java

Safe Language




Secure






No malloc(), free(), over/underflows in arrays
No pointers but “object references”
Sophisticated exception handling
Sandbox
Security Manager
Class Loader
Byte Code verifier
Applets can crash your browser/computer.
Signed Applets.
JavaScript




Intermediate between HTML and
Applets/Controls.
Developed by Netscape. (MS Jscript? )
No formal Security framework was designed.
(If it ain’t broke, why fix it?)
Good Thing – There is no JavaScript methods
that can directly access the files on the client
computer.
JavaScript security flaws

Loss of Confidentiality and Privacy.
 Create
and submit forms automatically.
 Access to browser’s “history”
 Upload file from user’s disk. (Are you smart?)
 A script running in one window can monitor the URLs
of pages in the other windows.
 DoS attack with CPU-intensive tasks.
 Windows System Attack (close 1, open 2)

DISABLE ON IMPORTANT MACHINES.
JavaScript spoofing Attacks
Username/Password pop-ups
 Browser status line spoofing

 microsoft.co.jp
 microsoft.com.attacker.com/setup.exe
 microsoft.co…/setup.exe
Web Privacy
What they know about you?
URLs of the sites you visited. (referer)
 Your IP address
 Your service Provider (Domain name)
 Your location, employer, e-mail, etc.
 Your Browser type
 Your surfing habits

How they know?

From Client Environment
 Browser
Variables
 Cookies
 Logs

From user-submitted data (Weblog)
 On-line
Purchase/Auction
 Online Banking
What is in a Weblog?








IP address and name of the computer accessed
the page.
Time
Exact URL
Download time
HTTP Authentication (y/n?)
Any errors?
Referer
Web Browser Type
Proxies and Anonymizers




Act as middle man.
Basically used by ISPs to reduce traffic.
(Cache)
Generally transparent to the end-user.
(Configure once or auto-configure)
Some proxies strip the “identifying information”
from web requests, making it impossible to trace
the source.
(Anonymizing Proxies)
Cookies



Small text files.
Original purpose was to track a client thru HTTP.
(Basically HTTP is stateless)
Use (nowadays)
 Shopping
cart (transient)
 weather.com (persistent)
 Username/password for subscription sites.
 Customize sites.
Cookie Abuse
Two different domains can’t share a
cookie.
 Cookies contain only the information YOU
gave to the web server.
 Problem?
If web servers collude to share info !!
(doubleclick.net)

Advice for users
Choose a good service provider.
 Pick a good password (and don’t write it !)
 Clean-up the system yourself

 Browser
cache (temp. Internet files)
 Cookies
 History

Use Anonymizer if possible.
Advice for Webmasters

Draft a written Privacy Policy
 Complete Anonymity
 User’s
identity recorded for in-house use only
 Info. Shared with selected sites.
 Cookies used to track uses anonymously
 Big Brother is watching

Keep yourself updated with legal issues.
Server side Security
Security Aspects for Server
Physical Security
 Host (OS) security
 Web application Security
 Deploying SSL
 Web Service

Physical Security







Locked Server (Floppy reboot)
Locked Server room (Unplug)
Dust, Temperature, Humidity
Fire, earthquake, lightning
Safe cabling/ network connections/ sniffers
Sanitizing media
Unattended terminals (Auto-logout/Scr. Savers)
Host (OS) Security



Minimize services (BIND and httpd)
Keep abreast of new vulnerabilities.
Use of Security tools
 Snapshot
tools (COPS, NAT)
 Change-detecting tools (Tripwire)
 Network scanning programs
 Intrusion Detection Systems
 Virus Scanners
 Logging tools

Firewalls (port 80 and 443)
Securing Web Applications



Web servers are fine applications for static
contents.
For Dynamic contents, use Extended Support
(Web-applications)
4 primary techniques to create web-apps.
 CGI
 Plug-ins,
loadable modules and APIs
 Embedded scripting languages (ASP, PHP)
 Embedded Web-server
Deploying SSL
Know the purpose to deploy SSL
 Decide the private key location
 Decide on just SSL or Dual mode.
 Test system on self-signed certificate
 Get CA certificate

Securing Web Service

Main objective is Reliable web service.

Know the price & performance v/s redundancy
Protect your DNS
Protect your Domain Registration


Safe CGI Scripting and Server
Modules (SM)
Both are executable programs with access
to file system, network and hardware
devices as any other program on the host.
 Parameters are passed to the programs
either in URL or by POST method.
 Server modules =
CGI + Access to web server’s data
structure and internal functions.

Common CGI/SM holes

Misuse of interpreters as CGI scripts
 Perl,

command.com, Java, TCL, PHP
Flawed memory management
 Statically

allocated memory (buf[255])
Passing user inputs without validation to
command interpreters.
/bin/mail –s ‘Test’ [email protected]; cat /etc/passwd
Common CGI/SM holes (contd.)

Opening files based on unchecked user
input
 ../../../etc/passwd

Writing unchecked user inputs to disk
 User
inputs with HTML tags in it.
Access Control
Hidden URLs
 Host-based (firewall)
 Domain-based
 Identity-based (user/pass, smart card)
 Client certificates (bank)
 Network security protocols (Kerberos)

Remote Authoring

Main ways to give authors access to the
server.
 Network
log-on (telnet, ssh, PcAnywhere)
 File Sharing (NFS)
 FTP Access (SSH+FTP ?)
 Web-server publishing Extensions
HTTP PUT,DELETE
 Frontpage remote web management tool.

Remote Administration
Via Remote Login (telnet, ssh)
 Via RPC
 Via Web-browser (IIS)

Reverse Proxy
Web Server behind firewall.
 Incoming requests are forwarded by the
firewall.
 Performance?

What we didn’t discuss
Client-side certificates
 Code Signing (Authenticode)
 Legal Issues.
 Firewall Configuration.

Conclusion

There is no single “Silver bullet” for web
security. There are lot of aspects to be
considered to achieve higher web security.
New technologies provide better features,
but they are also adding more
permutations to the pool of web security
threats.
References

Web Security, Privacy and Commerce, 2nd Edition
by Simson Garfinkel
Publisher: O'Reilly & Associates; 2nd edition (2002)
ISBN: 0596000456

Web Security: A Step-By-Step Reference Guide
by Lincoln D. Stein
Publisher: Addison-Wesley Pub Co; (1997)
ISBN: 0201634899
Questions ?
Thank you !