6 minutes
ICOM6045 Mobile Code Security
Mobile Code Security
Mobile code
- dynamically downloadable executable content is referred to as mobile code
- includes platform-independent executable content which is transferred over a communication network, crossing different security perimeters, and is automatically executed upon arrival at the destination host
- examples are Java applets, ActiveX controls, JavaScript, Safe-Tcl, servlet
- “browser helper applications” and plug-ins
- download from store
- download on demand
Mechanisms
- code signing
- least privileges
- code monitoring: resources usage monitoring
- mobile code runtime environment
- memory model partition the memory into safe and unsafe regions
- safety check ensure every memory access refers to a safe memory location, e.g. Java type safety
- resource access control by security manager, e.g. Java access controller
- proof-carrying code: the proof that a piece of mobile code adheres to a safety policy is encoded and transmitted together with the code
Java safety
- safety denotes absence of undesirable behavior that can cause system hazards, e.g.
- Java manages memory by reference and does not allow pointer arithmetic
- Java provides “final” modifier, which disables overriding class or method
- Java supports automatic memory management, which prevents memory leak and covert channel
- Java is a strongly typed language
- an object must always be accessed in the same way and illegal casting is impossible, e.g. an integer cannot be casted to a pointer and access anywhere in the system
- static type checking by bytecode verifier protects against forget pointers, access restriction violation, stack overflows, …
- dynamic type checking ensure no array bound overflows or type incompatibilities
- Java applet execution
- Java 2 security model
- using digital signature
- run-time access control
- stack check
- enable privilege
Java signed applet (code signing)
- definition
- there is a program (or a piece of code) sent from the Web server to the client (i.e. the browser)
- using the PKI and the browser technology
- example
- signed applet - Java applet with ‘digital signature’
- treat the applet as a ‘document’ from server to client
- the applet has a digital signature attached to it
- the “applet + digital_signature” is a signed applet
- when the server creates this applet, the server will put in this digital_signature as well
- only the server (which holds a “private key”) can create this digital_signature
- the “applet + digital_signature” is a signed applet
- client will verify the digital signature
- if the verification process is ok, client will allow the applet to execute
- result: only applet from trusted server will be executed
- yes or no answer
- “yes” means
- the web server (s1) providing the signed applet, is a valid customer of one of the CAs. So s1 is a good guy, and your PC or browser can execute this signed applet
- but you still have to look into the certificate details to see exactly who s1 is
- “no” means
- the web server (s1) providing the signed applet, is not a valid customer of anyone of the known CAs
- the browser let you decide whether to execute the signed applet or not
- “yes” means
ActiveX controls
- definition
- Microsoft’s collection of technologies and protocols for downloading executable code over the internet
- based on a technology that was not originally developed with network security issues in mind
- something “between” a plug-in and a Java applet: extend browser functionality and allow automatically downloaded with a web page
- types
- native machine code: most dangerous type
- Java bytecode: usually run inside the Java sandbox
- a mixture of native code and bytecode
- authenticode
- ActiveX controls can be digitally signed using authenticode, Microsoft’s digital signature technology using public key certificate
- a native code ActiveX control’s signature is checked only once: if the signature is valid and the signer is trusted, the control is downloaded
- a Java bytecode ActiveX control’s signature is also checked at downloading
- the actual access permissions are determined at runtime
- procedure in IE
- when IE downloads potentially dangerous content, it checks to see whether the code is digitally signed with a trusted certificate
- depending on your browser security setting (high, medium, medium-low, low, or custom) for the zone the content is originating from and the success or failure of the authenticode verification process, the browser determines whether or not to automatically run the content
- when prompted to allow or deny signed content, the user is allowed to inspect the signer’s digital certificate
JavaScript
- definition and advantages
- JavaScript provides a means of commanding the browser, including its graphical elements, from an HTML file
- JavaScript is inherently more secure than Java applets because it cannot directly access the file system or open network connections (sandbox)
- JavaScript are permitted to access only to data in the current document or closely related document (from the same site)
- no access is granted to the local file system, memory space of other running programs, etc
- JavaScript security
- principle
- there is no reason to trust randomly encountered code, and should treat them as hostile
- security issues
- it has access to all user information in the browser -> potential privacy violation
- DoS attacks are possible by opening a large number of windows until the browser freezes
- access control management: “same origin policy”
- scripts from one web site do not have access to information such as usernames, passwords, or cookies sent to another site
- e.g. using the handle returned by window.open(), the browser performs the same origin check
- verifying that the URL of the document in the target window has the same origin as the document containing the calling script
- 2 documents has the same origin if they were loaded from the same server using the same protocol and port
- example
- external script
- externally linked scripts are considered part of the page they are embedded in, and thus can be linked in from other domain
- e.g. the page at http://www.somesite.com/index.html could include the following script:
<script type=“text/javascript” src=http://www.example.com/scripts/somescript.js></script>
- this script will load and work as expected
- the linked scripts are considered part of the page they are linked into
- for the above example, if somescript.js tries access another window, it is considered to have come from http://www.somesite.com and subject to the some origin check
- principle
Summary
Security of Mobile Application
Mobile apps
- a mobile app is a computer program designed to run on a mobile device such as a phone/tablet or watch
- apps that are not preinstalled are available through distribution platforms app stores
Risks
- malicious behavior
- dangerous behavior
- moderate risk behavior
Security requirement for mobile apps
- traditional server-side requirement (much more than this in mobile security)
- IT system security architecture
- website security architecture
- mobile client-side requirement
- a device which can access to the system
- contains
- enabling authorized functionality
- preventing unauthorized functionality
- limiting permissions
- protecting sensitive data
- securing app code dependencies (e.g. heartbleed)
- testing app updates
- mobile app requirement
- understanding mobile platforms (e.g. iOS and Android)
- development APIs and security framework
- application permissions model (e.g. location, camera, microphone)
- data management and data storage
- shared data
- protected data
- handle personal data and cache
- data classification
- what data should keep on the device and what data should send back to the server
- data removal
- protecting network communications
- apps can communicate with the services though different media, e.g. WiFi or 4G
- how the apps interacts with the server
- certificate, key and trust services
- risk assessment
- does the app expose sensitive information of your backend system architecture
- e.g. password of the database, admin account
- can someone extract and modify your App to perform malicious actions
- does the app expose sensitive information of your backend system architecture
- understanding mobile platforms (e.g. iOS and Android)