Preventing Data Leaks from Compromised Web Applications - SilverLine Overview
Learn about SilverLine, a system designed to prevent data leaks from compromised web applications by decoupling data protection from the application, associating users with sessions, tracking data, and declassifying responses. Understand the common server-side vulnerabilities and current protection mechanisms to safeguard against data breach incidents. Explore the design goals and non-goals of SilverLine architecture to enhance security and minimize performance overhead.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
SilverLine: Preventing Data Leaks from Compromised Web Applications Yogesh Mundada Anirudh Ramachandran Nick Feamster Georgia Tech 1 Appeared in Annual Computer Security Applications Conference (ACSAC) 2013
Data Breach Incidents Sony Data Breach (SQL Injection, 2011) Citibank (Web application vulnerability, 2012) Twitter (2013) Adobe (2013) 90% of the data leakages occur at server. 95% of those leaks are from external attacks. 2
Common Server-Side Vulnerabilities Injection Attacks Broken Authentication and Session Management Insecure Direct Object References Security Misconfiguration Vulnerable Components and Libraries (Open Web Application Security Project) 3
Current Protection Mechanisms Penetration testing Automated code review Application firewalls Data loss prevention devices Shortcomings No protection against zero day attacks Once compromised, can t stop data theft Focus on protecting data, rather than the underlying system 4
Design Goals Security: Decouple data protection from the application Deployment: Minimize changes to existing applications Performance: Minimize overhead 5
SilverLine Design Non-Goals Kernel-level vulnerabilities Covert channels Malicious software on the database Inside threats Data modification attacks 6
SilverLine Overview Step #1: Tag Sensitive Data Step #2: Associate User with Session Step #3: Retrieve Data with Taints Step #4: Track Data Step #5: Declassify Response 7
SilverLine Components Authentication Module Database Proxy Information Flow Monitor Declassifier 8
SilverLine Architecture 1. User sends Login request 6. Execute query Database Proxy Process 10 Webserver Process 16. Return Response 14. Send Response 12. Query Results Web Application Database 8 7 Server Query Parser Process Query RegEx Table Declassifier Process 9 Information Flow Tracking Kernel Firewall Database Node 2. Authenticate User 15. Check Session Permissions Connection- Capabilities Table Trusted Realm 4. Cookies User Untrusted Realm 3. Authenticate User-Auth Table Authentication Module Database Table User-Sessions Table 5. 5-tuple taints Process Authentication Node 9
Step #1: Initial Configuration Indentify and mark sensitive tables Find unique user key Find foreign keys Find table groups Find tables to monitor for insert query Create taint-storage tables in each group 10
Step #1: Configuration Example User Table User-Taint Table User-ID Name Transact-ID User-ID Taint 1 A 1 John Smith 100 2 B 2 Jane Doe 200 Transaction Table Transact-Taint Table SELECT Name FROM User WHERE User-ID = 2 Transact-ID Transact-no Item Transact-ID Taint 100 A 200 37 DVD 200 38 PHONE 200 B SELECT Name, Taint FROM User u, User-Taint ut WHERE User-ID = 2 AND u.User-ID = ut.User-ID SELECT Item FROM Transaction WHERE Transact-ID = 200 and Transact-no= 37 100 89 BRUSH SELECT Item, Taint FROM Transaction t, Transact-Taint tt WHERE Transact-ID = 200 and Transact-no= 37 and t.Transact-ID = tt.Transact-ID11
Step #2a: Authenticate User 1. User sends Login request Database Proxy Process Webserver Process Web Application Database Server Query Parser Process Query RegEx Table Declassifier Process Information Flow Tracking Kernel Firewall Database Node 2. Authenticate User Connection- Capabilities Table Trusted Realm User Untrusted Realm User-Auth Table Authentication Module Database Table User-Sessions Table Process Authentication Node 12
Step #2b: Decide Session Capability 2. Authenticate {username, password} 5. Store {SIP:SP-DIP:DP-Prot, Taint1} Connection- Capabilities Table User 3. Verify & Authenticate User-Auth Table Authentication Module User- Sessions Table 4. Store {Cookie1, User1} 4. Verify Cookie Authentication Node Trusted Realm Process Database Tables 13
Step #3: Retrieve Taints with Data 1. User sends Login request 6. Execute query Database Proxy Process Webserver Process Web Application Database Server Query Parser Process Query RegEx Table Declassifier Process Information Flow Tracking Kernel Firewall Database Node 2. Authenticate User Connection- Capabilities Table Trusted Realm 4. Cookies User Untrusted Realm 3. Authenticate User-Auth Table Authentication Module Database Table User-Sessions Table 5. 5-tuple taints Process Authentication Node 14
Step #3: DB Proxy Operation 6. Execute query from Webserver Database Proxy Process 10. Execute Data + Taint Retrieval Query 12. Return results To Webserver Web Application Database 8. Parse Query And generate Regular expressions 11. Store {5-tuple, Taint} 7. Match Regular Expression Query Parser Process Connection Taints Table Query RegEx Table 9. Store Query, Taint Query Trusted Realm Process Database Tables 15
Step #3: Apply Taint to Connection UserID Username SSN UserID Taint Database Server 1 0xABCDEF 1 Alice 999-99-9999 2 0x123456 2 Bob 888-88-8888 user table user_taintstable Modified Query by Proxy Data Query SELECT name, taint from user u, user- taints ut WHERE UserID=1 and u.UserID=ut.UserID Database Proxy SELECT name from user WHERE UserID=1 Taint applied to network connection Query Results 0xABCDEF 1 Alice 999-99-9999 1 Alice 999-99-9999 16
Step #4: Track Data 1. User sends Login request 6. Execute query Database Proxy Process 10 Webserver Process 12. Query Results Web Application Database 8 7 Server Query Parser Process Query RegEx Table Declassifier Process 9 Information Flow Tracking Kernel Firewall Database Node 2. Authenticate User Connection- Capabilities Table Trusted Realm 4. Cookies User Untrusted Realm 3. Authenticate User-Auth Table Authentication Module Database Table User-Sessions Table 5. 5-tuple taints Process Authentication Node 17
Step #4: Information Flow Tracking Per-process taint records Monitors system calls IPC {send, shmat, kill}, File/Device operations {read, unlink}, Process management {fork, execve}, Memory {mmap}, Kernel configuration{sysctl} Taint transfer with information exchange Network database connection-taints to transfer taints across machines 18
Step #5: Declassification 1. User sends Login request 6. Execute query Database Proxy Process 10 Webserver Process 16. Return Response 14. Send Response 12. Query Results Web Application Database 8 7 Server Query Parser Process Query RegEx Table Declassifier Process 9 Information Flow Tracking Kernel Firewall Database Node 2. Authenticate User 15. Check Session Permissions Connection- Capabilities Table Trusted Realm 4. Cookies User Untrusted Realm 3. Authenticate User-Auth Table Authentication Module Database Table User-Sessions Table 5. 5-tuple taints Process Authentication Node 19
Implementation 60 lines in OSCommerce Information Flow Control 8,000 lines of C Linux kernel code Redis key-value store User-Session Connection-Capabilities Connection-Taints Taint-Policy Database proxy 350 lines of Lua code 20
Implementation Configuration Identify primary keys Table groups Foreign key relationship Insert query monitoring for each group In OSCommerce application: Out of 50 tables, 15 were sensitive Tables were grouped in sets of 9, 5 and 1 In all we needed 3 taint-storage tables 21
Evaluation File fetch (small: 7%, large: 1%) Scalability: Login slowdown (21%) User session slowdown (30%) 22
Related Work Data Isolation CLAMP, Nemesis CryptDB Information Flow Control HiStar, Dstar, Asbestos, Flume Language-level Taint Tracking RESIN, Guardrails, PHPAspis, DBTaint Full-system Taint Tracking TaintDroid, Neon, Panorama 23
Conclusion SilverLine: Protect data, rather than the application Prevent exfiltration of sensitive data, even if the application is compromised Information flow: associate data with taints, only allow authorized user sessions to access Very little modification to existing applications Overhead is about 20 30% over unmodified applications 25
