1 / 18

JSProxy: Safety from Javascript

JSProxy: Safety from Javascript. Benjamin Prosnitz, Tang Yi, Yinzhi Cao. Motivation. Most web attacks today are performed through JavaScript Vulnerabilities in the execution engine Invocations of vulnerable plug-in code. Goals. Run Javascript code remotely in a way that

gilligans
Download Presentation

JSProxy: Safety from Javascript

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. JSProxy: Safety from Javascript Benjamin Prosnitz, Tang Yi, Yinzhi Cao

  2. Motivation • Most web attacks today are performed through JavaScript • Vulnerabilities in the execution engine • Invocations of vulnerable plug-in code

  3. Goals • RunJavascript code remotely in a way that • Does not require client modification • Is high performance • Maintains original functionality • Test whether the JavaScript code performs an attack • Filter code when it can be done safely Future

  4. Running Javascript Remotely • Modify pages viewed by client • Replace original scripts with remote calls (AJAX) • Repeat the user’s actions on the server • Send changes made by scripts that should be visible to the user back to client

  5. Diagram of System Proxy Javascript Execution Engine (modified browser) Web Server Proxy Interface Modification Engine Session Manager Interface User

  6. Timeline of Events Request for page Server Inject button press Proxy Original Page t Changes to page Changes to page Button Pressed (it is really asynchronous) Client Modified Page remote_call()

  7. DEMO: Page Modification • Uses Mozilla Gecko engine • Searches for javascript and replaces it with calls (which will eventually be remote calls) • Suggest a URL to download and modify!

  8. Performance of Page Modification CDF of Processing Time

  9. Performance of Page Modification Strong correlation between Page Size and Processing Time

  10. Performance of Page Modification Processing Time is not clearly correlated with Number of Scripts

  11. Interface and Session Management • Client-server interface using Javascript/AJAX and FastCGI/C++ (not being demoed today) • Session manager which • Identifies sessions that are alive and dead • Redirects calls to the correct browser session • Closes browser sessions which have ended

  12. DEMO: Executing Javascript on Proxy • Browser on Proxy is Webkit-based • Remote execution of Javascript code would occur when user performs an action

  13. DEMO: User-Visible Change Detection • Also based on Webkit • Can detect approximately 8 different changes now • .innerHTML changes • alert() • print() • close() • …

  14. Where is state (cookies,etc.) kept? • On both client and proxy • Proxy needs it to have javascript (esp. AJAX) work as expected • Client needs it to submit forms, display the data, etc.

  15. Future Work: Remote Execution • Create session manager • Finalize interface • Detect and fix cases that it doesn’t work with

  16. Future Work: The Filter • Acquire or implement a virtual-machine based vulnerability detector • Determine how to safely identify which pages to run remotely • Implement a mechanism to transparently switch between remote and local page execution

  17. Conclusion • Work on our system is in progress and will continue next quarter • Key components of the remote execution system are currently functional and work well • The remainder of the remote execution system can likely be finished soon

  18. Q&A?

More Related