1 / 15

Security by Contract (SxC) for web applications

Security by Contract (SxC) for web applications. Frank Piessens – Fabio Massacci – Lieven Desmet (and the whole S3MS consortium). Motivation. Dec 2008: W3C workshop on Security for Access to Device APIs from the Web From the CFP:.

zuzana
Download Presentation

Security by Contract (SxC) for web applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Security by Contract (SxC) for web applications Frank Piessens – Fabio Massacci – Lieven Desmet (and the whole S3MS consortium)

  2. Motivation • Dec 2008: W3C workshop on Security for Access to Device APIs from the Web • From the CFP: With the emergence of the Web as a compelling alternative to locally installed applications, security issues are an increasing obstacle for realizing the full potential of the Web, in particular when Web applications developers need to get access to features not traditionally available in the browsing environment: cameras, GPS systems, connectivity and battery levels, external applications launch, access to personal data (e.g. calendar or addressbook), etc.

  3. Contents • Background: Security by Contract • SxC for the web • Policies • Enforcement technologies • Trust model • Conclusion

  4. Background: Security by Contract • Security by Contract (SxC) is an approach to security for “Code on Demand” worked out in the European FP6 project S3MS • Motivating scenario: • The virtual tourist guide • None of the existing approaches is satisfactory: • Doing nothing • Sandboxing • End-user approval • Code signing (or other evidence of origin) • Policy enforcement

  5. Background: Security by Contract • Problem statement • Can we support flexible security policies for code on demand • Without relying on trust in code origin • Without relying on end-users having to make trust decisions or write policies • Key idea of Security by Contract • We can do this by involving all stakeholders in a negotiation of the security properties of code • As pioneered in PCC and MCC!

  6. Security by Contract (SxC) • Key concepts: • System policy: the policy that the executing system should enforce on applications • “What applications are allowed to do” • Technically: a security automaton over API interactions • Application contract: a description of the security relevant behavior of the application • “What the application might do” • Technically: a security automaton over API interactions

  7. Example policy • Informally: do not send more than 10K on the network • Security automaton (in CONSPEC) SECURITY STATE intbytesSent = 0; BEFORE System.Net.Sockets.Socket.Send(byte[] array) PERFORM bytesSent + array.Length <= 10000 -> { } AFTER int sent = System.Net.Sockets.Socket.Send(byte[] array) PERFORM true -> { bytesSent += sent; }

  8. Example contract for “SMS chess” SECURITY STATE intbytesSent = 0; intsmsSent = 0; BEFORE System.Net.Sockets.Socket.Send(byte[] array) PERFORM array.Length == 20 && bytesSent + array.Length <= 2000 -> { } AFTER int sent = System.Net.Sockets.Socket.Send(byte[] array) PERFORM true -> { bytesSent += sent; } BEFORE Microsoft.WindowsMobile.PocketOutlook.SmsMessage.Send() PERFORM smsSent <= 100 -> { } AFTER Microsoft.WindowsMobile.PocketOutlook.SmsMessage.Send() PERFORM true -> { smsSent += 1; }

  9. Security by Contract (SxC)

  10. Supporting technologies • Development time: • Static analysis/verification of compliance with contract • Inlining of contract enforcement • Model-based security testing (contract = model) • Deployment time • Signatures • Proof-carrying-code • Contract-policy matching • Run time • Monitoring (inlined or external)

  11. SxC for the web • Can SxC can be applied “out-of-the-box” to the client part of web applications? • Is monitoring the web app’s interactions with an external API a solution to the W3C device access challenge? • There are several issues that need to be resolved to make SxC useful on the web • Policies • Enforcement technologies • Trust model

  12. Policies • What is a good formal model for policies and contracts for web applications? • Security automaton over API invocations does not seem sufficient • Dealing with information flow • Dealing with the server-side of the application • What are web application security researchers using as policy models?

  13. Enforcement technologies • Even though there is no formal definition of what we want to enforce, it is already clear that some of the supporting technologies will break • Monitoring for information flow is expensive/imprecise • Monitoring a remote piece of software needs attestation / trusted computing techniques that seem immature

  14. Trust model • In the mobile phone scenario, the platform providers and the telecom operators played a key role in negotiating policies and contracts, and in proxying the end-user. • Who should play that role on the web? • Microsoft? Google? • ISP’s? • Should we restrict attention to specific classes of code (eg. Untrusted Javascript pulled in a containing web page: BEEP-like …)?

  15. Conclusion • SxC is a promising approach for dealing with code on demand security in some scenarios • Instantiating SxC for web applications seems to be hard. Several research challenges remain: • Formally defining policies • Enforcing / matching such policies • Trust models

More Related