Lecture 11

1. Lecture 11 WWW Security and Java Security Ref. Chapter 11

2. Contents Part 1: WWW Security • Introduction • Web browser • Scripts • Web applications Part 2: Java Security • Java language features • Java platform • Applet vulnerabilities • Servlet security

3. The properties of WWW security • Separation of program and data is abolished. Executable content (applets) in documents. • Computation is moved to the client. It is now the client who needs protection from rogue content providers. • Mobile code moves from machine to machine. Clients need protection from mobile code; mobile code may need protection from clients it is running on. • Users are forced to become system administrators and policy makers.

4. Web Browser • Is a program that presents the user with a GUI and includes the protocols necessary to connect to the web. • Presents the attractive web pages; • Is a service layer for web applications; • Includes the protocols for communication with web servers; • Manages security relevant information for the client. • Web security model • The Client: • The Client’s browser: • The Server: more about the software.

5. Why are browsers taken as a part of TCB? • Handle the clients’ web traffic. • Manage the default settings and preferences for client environments. • Keep a history and a cache of recently visited pages. • Encryption and digital signature. • Integrate communications services such as email. • May run in system mode • Assume more and more functions of OS

6. CGI Scripts • CGI (Common Gateway Interface) is a meta-language for translating URLs or HTML forms into runnable programs. • Server • executes Client URL, HTML form CGI script

7. CGI script security problems • Cat the file| mail client address • To ask the client to input a file to a client • If input a.txt haibinz@nipissingu.ca | rm –rf/ • it will delete all the files permitted by the script at the server.

8. JavaScript Scripting languages: • expand the capabilities of Web pages by supporting interaction • most popular Active Scripting languages are Netscape’s JavaScript and Microsoft’s VBScript.

9. What JavaScript can do • JavaScript resides within HTML documents and is executed on the client • Is used primarily to respond to any user events such as mouse clicks, navigation and form validation • Saves on client/server interaction and its associated overheads • prevent users from sending rogue data that could damage the server, so faster and less load on the server • Examples: • http://psych.fullerton.edu/mbirnbaum/brmic/

10. JavaScript limitations • no compile-time system of classes • runtime system is based on a small number of simple data types • only loosely typed so pretty undisciplined • programmer free to create objects e.g. window, frame, document, and manipulate them • possible for JavaScript to “pop-up” some friendly windows, submit a data form and re-forward it to other URL’s (privacy issues) • Javascript security • http://linux.omnipotent.net/article.php?article_id=12426

11. Cookies • A message given to a Web browser by a Web server. The browser stores the message in a text file. The message is then sent back to the server each time the browser requests a page from the server. • Server Client Browser Cookies

12. Web Application • all communication is via web pages • HTTP used for getting input from and output to the client • Client data is sent to the server using HTML forms which may include hidden as well as visible data fields • each page is generated by the web server in response to input provided by the user at the client Client Server

13. Applets: Small Java programs attached to web pages which are loaded and run in web browsers. Spice up web pages by providing user interaction and animation Servlets: Programs which run on the server Enable web server to respond directly to client interaction Generate HTML in response to client requests Java Web Application

14. Client-side Security Activities(1) Signing Applet: • is invoked when user hits a button • must download all the signing software it needs to compute signature i.e. many class files for implementing RSA • displays a text box for user password • password needed for access to the user’s private signing key (software token or hardware token) • needs trusted status to access user file space: a signed file is used

15. Client-side Security Activities(2) • the bid, the computed signature and the user’s digital certificate (read from security token) are packaged by the signing applet into an encrypted object • this object is sent to the Server as a (hidden) hex-encoded string within a form

16. Software v Hardware tokens(1) • Key Generation • Clear advantage if key is generated within secure device; its use can be demonstrated at registration • Signing • Execution in risky because interrupts, memory dumps etc can be used to some effect by hackers

17. Software v Hardware tokens(2) • Key Storage • Storage allows file to be copied and “brute-forced” at leisure; copying will not be evident • A Key is tamper evident; obvious if stolen or lost; • Some protection against brute force attack • (counts unsuccessful login attempts) • A Key affords protection against attackers or rogue programs stealing information

18. ImplementationServer processing(1) Server • runs servlet requested by client on submission of a form • servlet extracts data from the form and processes it • including the digital signature • servlet generates html for responding a web page • whether signature valid and if so whether bid is accepted

19. ImplementationServer processing(2) What does the server need in order to verify the digital signature? • signer’s public key • signer’s digital certificate • ability to traverse a certificate chain

20. Server-side Security activities • When the servlet invoked by a client command the web page receives the encypted object it must unpack it to verify the signature using the included digital certificate • Server must access verification software and online directories • in practice a certificate chain would need to be traversed until a trusted CA (certification authority) was encountered • online CRL (certified resource locator) must be checked as part of the verification process.

21. Applet/Servlet Architecture Source: McGraw & Felten

22. Part 2 Java Security History • open development/documentation from 1995 by Sun Microsystems (JDK) • platform-independence vital to program mobile code and executable content for the Internet and the Web • as a result sound security features designed in from the start

23. Aspects of Java Security We look at these aspects: • Java language features • Java platform • Applet vulnerabilities • Servlet security

24. Java Language (1) Java is object oriented: • is a “natural” way of thinking, matches the real world • data-centric: data objects possess associated methods • unlike old procedural way of thinking with C and Pascal • a class is a template for a data object and its methods • each class is one kind of object • every Java program is composed of one or more classes

25. Java Language (2) Java supports inheritance • hierarchy of classes supports inheritance of behaviour and structure • GUI: windows, dialogue boxes, scroll bars, text boxes, check boxes • very powerful, supporting code re-use • “write once, run forever”

26. Security Relevant Features • Security aspects of object orientation • Strong type system • Sound error handling with exceptions • System keeps track of memory management: automatic garbage collection Without these properties security holes can exist as a result of programmer error or poor design that hackers can exploit

27. 1. Object Oriented Aspects relevant to better design for security: • data hiding • data items are “hidden” within classes • data objects cannot be accessed directly, only through their “public” interfaces (some access control at this level) • abstraction • Seeing the big design picture, postponing details of implementation • programmers cannot access memory directly, must use object references • no pointer arithmetic (the most bug-prone aspects of C and C++) Makes it hard for rogue code to trawl through memory looking for passwords or credit card numbers

28. 2. Strong Type System • essential aspect of Java security • stops arbitrary access to host memory • memory access by Java programs is limited to specific controlled areas having particular representations • type safety supported by compile-time and run-time checking • E.g. array bounds checks, immutable strings Provides significant protection against buffer overflow attacks

29. 3. Error Handling • Handling of error conditions is error-prone! • Java’s exception handling allows for neat handling of error conditions without crashing the system. e.g. If a Java program tries to open a file without the correct privileges, an exception will be “thrown”; there is a logical structure for programmers to “catch” exceptions for a graceful, crash-free, exit. • System crashes can lead to exposure of sensitive data.

30. 4. Garbage Collection System keeps track of memory usage instead of the programmer. • Java’s garbage collector uses a low priority thread to run silently in the background • Frees the programmer of the need to allocate and de-allocate memory explicitly • Prevents all sorts of bugs that are difficult to eliminate e.g. dangling pointers

31. Platform Independence • All java source code (class files) is compiled into portable bytecode • To execute bytecode requires a run-time environment, a Java Virtual Machine (JVM) which interprets the bytecode into the machine code for a particular machine • The JVM is an abstract computing machine and does not assume any particular implementation technology or host platform

32. Basic Security Architecture In the original Java 1.0 release the distinction between applets and applications was assumed to be clear: • applets are downloaded from an outside source to be run • typically from within a Java enabled browser • activities need to be constrained to a sandbox • applications reside on the local machine • can be trusted • granted full access to system resources

33. Java Security Architecture

34. Challenges • Users cannot rely on prior acquaintance and trust relationship with the source of an applet. • Few users are willing to rule personally on each access request made by an applet. • The client’s operating system cannot be expected to offer any protection.

35. Language design considerations • It should make it more difficult for programs to create damages. • The execution environment provides mechanisms for access control. • The security policies enforced by the execution environment have to be set correctly.

36. Security considerations for applets • Applets do not get access to the user’s file system. • Applets cannot obtain information about the user’s name, email addresses, machine configuration, etc. • Applets may make outwards connections only back to the server they came from. • Applets can only pop-up windows that are marked ‘untrusted’. • Applets cannot re-configure the system.

37. The Byte Code Verifier • It guarantee: • The class file is in the proper format; • Stacks will not overflow; • All operands have arguments of the correct type; • There will be no data conversion between types; • All references to other classes are legal.

38. The Applet Class Loader • Protect the integrity of the run-time environment. • Applets are not allowed to create their own class loaders and interfere with each other. • Each class loader has its own name space . • When referring other classes, the applet class loader first searches the built-in classes in the local name space. If not found, extended to the namespace. Therefore, no “spoof” happens.

39. The Security Manager • It is the reference monitor of the Java security model. • It guards a predefined list of critical operations and enforces application-defined controls over these operations.

40. The SecurityManager class • abstract class SecurityManager • { • checkAccess(Thread); • checkAwtEventQueueAccess(); • checkConnect(String, int); • checkCreateClassLoader(); • checkExec(String); • checkPropertiesAccess(); • checkRead(FileDescriptor); • checkWrite(FileDescriptor); • } • Class MySecurityManager extends SecurityManager • {//… • }

41. The Security Policy Files • When code is loaded or remotely accessed it is assigned permissions based on the security policy currently in effect for the code and access. • Jre/lib/security/java.policy • A policy file contains a number of grant entries and an optional keystore entry. • keystore “keystore.url”, “keystore_type” • grant signedBy “signer_names”, codeBase “URL” • permission permission_class “target_esource”, “action_allowed”, signedBy “signer_names”

42. The Default Java Sandbox The source of an applet may be unknown, so Java 1.0 implemented a sandbox policy for severely restricting the “play area” of all applet code • May access CPU, its own memory and web server from which it was downloaded • No access to file store • Byte code verifier subjects code to a series of tests

43. Java 1.0: Original Sandbox Model(1) Source: McGraw & Felten

44. Java 1.0: Original Sandbox Model(2) Applet code is compiled into bytecode at source and downloaded from server to client with HTML for web page. • Applet is invoked • Run time environment in browser verifies byte code • Instantiates the applet class (and other classes) in a constrained namespace • Executes the applet within the namespace • Potentially dangerous calls checked by the security manager • Allowed or not depending on origin

45. Java 1.1 Signed Applets • JDK 1.1 introduced the concept of trusted applets • added support for digital signatures so that an applet’s class files, after their development, could be signed and stored together with their signatures in JAR (Java Archive) format • JDK allows you to specify which signers are trusted • Trusted applets can be treated as local code and given full system access

46. Java 1.2 (1) • distinction between applets and applications disappears • classes judged very much on their own merits by considering source and signer • built-in classes still trusted • applets may now be trusted and applications may be untrusted • partially trusted code can be placed in a specially constructed sandbox • can default to original sandbox model

47. Java 1.2 (3) Provides: • Fine-grained access control • Can specify gradual reduction of sandbox constraints • AC made easily available to user and developer • Configurable policy • Developers and users can set/manage own security policies • Ability to type and group permissions in policy-oriented constructs But requires clear attention to POLICY!

48. Applet Vulnerabilities Insecure Java applets can be either • Malicious: annoying, crashing the browser or DOS - found in the wild • Attack: potentially taking control of the machine - not found on the Internet, but created by researchers in the lab (see www.rstcorp.com/javasecurity/)

49. Servlet Security (1) Servlets: • do not pose the same security problems as applets • code is probably local and trusted • face the usual threats to Web servers, often around denial of service

50. Servlet Security (2) Small improvements in security over competing technologies: • Run in same process space as server (unlike CGI), only loaded once without overhead of loading a different process for each call • All client requests serviced by separate threads so faster context switching, so some protection against DOS attacks