WO2011018316A1

WO2011018316A1 - Web browser security

Info

Publication number: WO2011018316A1
Application number: PCT/EP2010/060619
Authority: WO
Inventors: Masood Syed Ghouse
Original assignee: F Secure Oyj
Current assignee: WithSecure Oyj
Priority date: 2009-08-12
Filing date: 2010-07-22
Publication date: 2011-02-17
Anticipated expiration: 2012-02-12

Abstract

A method of controlling the sending of sensitive electronic data from a client terminal to a peer over the Internet, the client terminal implementing a web browser for displaying and interacting with webpages. The method comprises, at the client terminal, identifying a URL associated with an html form tag of a webpage, and querying a reputation database in order to obtain a rating for the URL. In dependence upon the rating, the sending of data entered into the field(s) of the form over the Internet is blocked, and/or a warning displayed to the user.

Description

WEB BROWSER SECURITY Technical Field The present invention relates to web browser security and in particular to a mechanism for preventing sensitive information being sent from a web browser to a malicious website.

Background

Most users of the Internet are by now familiar with so-called "phishing" attacks, where an attacker seeks to gain access to a user's sensitive information, e.g. bank account details, passwords, etc, by sending to the user an unsolicited email containing an innocent looking link. If the user clicks on the link, he or she is directed to a URL that loads a webpage into the user's web browser and which is a copy of a seemingly legitimate webpage. The displayed page may contain fields into which the user is requested to enter sensitive data. The html construct for displaying such fields is the form construct. If the user chooses to submit the form, the sensitive data is sent to a URL associated with the form in the html data. Even if a user clicks on the malicious link in the first instance, he or she may well spot the attack by observing that the address line appearing in the web browser window is not a trusted address. For example, where the trusted address of a user's bank is "www.mybank.com", that appearing in the browser's address line may be "www.mybank1 .com". Moreover, certain security or "anti-virus" applications may be able to detect phishing attacks by both scanning emails and monitoring outgoing browser traffic to detect suspicious URLs, albeit without achieving 100% security.

Attackers are constantly changing and improving their strategies to counteract new security measures. Due to the reduced effectiveness of phishing attacks, many are now resorting to more ingenious forms of attacks. One such attack involves tricking a user into running a piece of code or "script" in his or her web browser which modifies only a part of an otherwise valid webpage. Typically, the part which is modified is the destination URL to which form data is submitted. Figure 1 shows an example piece of html code that creates within a displayed webpage a form with two input fields, "firstname" and "lastname", and one submit button. Figure 2 shows how a malicious script may modify the destination URL ("www.example.com/getform.asp") associated with the action, to match a malicious site, in this case "www.stealyourdata.com/getform.asp".

In order to modify a downloaded website, a Cross Site Scripting (XSS) attack may be used. A so-called "reflective" XSS attack can be carried out by enticing the user to click on a link that contains as its root a trusted website address, and in addition a malicious script, e.g. "www.mybank.com/maliciousscript.js. The browser sends a GET request to this URL, and the request is indeed received by a server of mybank. The server expects to receive, appended to the URL, the user's username and password, and reflects these back in the returned webpage, e.g. the page contains the message "hello maliciousscript.js". The browser receives the webpage data, recognises the script, and executes it. Execution of the script results in the display of an otherwise valid webpage, but with the destination URL of one or more forms changed to a malicious URL. Of course, this URL is not displayed to the user and, importantly, the address line of the browser window shows only a legitimate URL, e.g. "www.mybank.com/login".

A related, but potentially more dangerous XSS attack is that known as a "type 2" or persistent XSS attack. A type 2 XSS attack takes advantage of the fact that users may post html formatted data at a web application of a web server in a persistent manner. This might be the case for example with a web chat application. When a client reads the web page, e.g. chat board, a malicious script may be downloaded and executed by the client's web browser in order to modify the destination URL of a web page form.

A number of products designed to reduce the problems discussed above are available. One approach employed is to detect when a user enters potentially sensitive information into a form field. For example the insertion of an "@" character may be detected as indicative of entry of a user's email address, or an algorithm such as an Luhn algorithm used to detect the entry of a credit card number. A warning is displayed to the user, and the user must click the warning away in order to proceed. Of course, as the majority of form data submitted by a user is likely to be legitimate, such an approach may prove an annoying inconvenience. Summary A "brute force" defence against phishing and pharming attacks of the type described above is to screen destination URLs for all outgoing traffic from the web browser. However, this is slow and inefficient, and may result in a delayed response for all browser requests. An improved, or at least supplementary approach that is presented here is to detect either the presence of a form in a webpage or an attempt by a user to submit a form, and to check the associated URL against a database of rated URLs. Depending upon the result of the check, the URL submission can be blocked and/or a warning presented to the user.

According to a first aspect of the present invention there is provided a method of controlling the sending of sensitive electronic data from a client terminal to a peer over the Internet, the client terminal implementing a web browser for displaying and interacting with webpages. The method comprises, at the client terminal, identifying a URL associated with an html form tag of a webpage, and querying a reputation database in order to obtain a rating for the URL. In dependence upon the rating, the sending of data entered into the field(s) of the form over the Internet is blocked, and/or a warning displayed to the user. The step of identifying a URL may comprise parsing html code of said webpage to identify a form tag and an associated URL. Alternatively, this step may comprise intercepting and parsing outgoing http data to identify the URL.

Said steps of identifying, querying, blocking, and displaying may be carried out by a web browser plugin.

The step of querying a reputation database in order to obtain a rating for the URL may comprise formulating a query at the client terminal containing said URL and sending that query, across the Internet, to a reputation server, and, upon receipt of the query at the rating server determining a rating for the URL and sending a response containing the rating to the client terminal.

The step of querying a reputation database in order to obtain a rating for the URL may comprise querying a rating database maintained at the client terminal. According to a second aspect of the present invention there is provided a computer program for use with a computer provided with a web browser for displaying and interacting with webpages. The computer program causes the computer to identify a URL associated with an html form tag of a webpage, and query a reputation database in order to obtain a rating for the URL. In dependence upon the rating, the program blocks the sending of data entered into the field(s) of the form over the Internet and/or displays a warning to the user.

The computer program may be implemented as a web browser plugin.

According to a third aspect of the present invention there is provided a computer storage medium having stored thereon a computer program according to the above second aspect of the invention. According to a fourth aspect of the present invention there is provided a client terminal comprising a computer storage medium according to the above third aspect of the invention.

Brief Description of the Drawings

Figure 1 shows an example html code segment that creates within a displayed webpage a form;

Figure 2 shows an example html code segment with a modified destination URL;

Figure 3 is a flow diagram illustrating a process for handling webpage form submissions to detect suspicious activities;

Figure 4 illustrates schematically a client terminal configured to implement the process of Figure 3.

Detailed Description

Detecting malware and other security threats in a client terminal environment can, if not properly optimised, consume large amounts of computer resources to the point where the performance of the terminal is severely impacted. As has been discussed above, the brute force monitoring of all outgoing Internet traffic is particularly undesirable given that users have become used to extremely fast broadband browsing experiences. A more efficient approach presented here involves detecting either the presence of form fields in a webpage, or when a web browser is attempting to submit form data across the Internet, and using this as a trigger to "scan" the URL submit destination. Appropriate functionality can be introduced into a client terminal by way of a browser plugin, i.e. a program that makes use of standard interfaces of the browser to enhance the browser's operation. Browser plugin technology is well know to those of skill in the art.

Figure 3 presents a flow diagram illustrating an approach employing monitoring submitted forms. At step S1 , the user has clicked on a submit "button" in order to submit the content of a form to a destination URL. The submission is intercepted at step S2. At step S3, the destination URL for the submission is identified. Browsers provide several methods that can be used to implement steps S2 and S3. One approach employs JavaScript generated 'event notifications'. For example, the onclickO event is triggered whenever a certain element is "clicked". These events can be detected by script code segments in the webpage or by a browser plugin. Whenever a form submission occurs, at least the onsubmit() event is triggered by the browser. This event can be used by a script code segment or JavaScript to intercept the submission as required.

At step S4 a query containing this URL is formulated and sent to a URL associated with a trusted server operated by an anti-virus application provider. The query may be digitally signed (and possibly encrypted) to authenticate the sender to the server. At step S5, the server receives the query and extracts the destination URL. The server looks up this URL in a website reputation database. The database will have been constructed by the provider from an analysis of publicly available websites, e.g. using a "spider" to collect webpages and some automated malware detection process for analysing collected webpages. Data may also be entered manually into the database, e.g. based upon user reports of good and bad websites.

The result of the query is returned to the querying client terminal, again with the message signed (and possibly encrypted) to authenticate the server as the origin. The client terminal must of course verify the signature to authenticate the response. At step S6, if the response indicates that the URL is trusted, the web browser plugin allows the submission to proceed, i.e. forwarding the submission to the destination URL. If on the other hand the response indicates that the destination URL is malicious, suspicious, or unknown, the plugin blocks the submission and displays an alert to the user at step S8. The alert may be displayed in separate, pop-up window, or in a dedicated area of the browser frame, e.g. as a "traffic light" indicator. In response to the alert, the user may be able to force a submission, at least for unknown URLs.

Figure 4 illustrates schematically a client terminal in the form of a PC 1 (the terminal may of course be any other computer device with Internet connectivity, e.g. a mobile phone). The PC comprises a display 2 on which might be displayed the graphical user interface (GUI) of a web browser 3, e.g. Internet Explorer™. A memory component 4 stores a computer software 5 which, when executed, provides a browser plugin for the web browser. As well as implementing the background URI scanning described above, the plugin also modifies the displayed GUI, for example to display an indication that a form submission has been allowed or blocked. The PC further comprises a network interface 6 for coupling the PC to the Internet.

An alternative approach to defending against attacks of the type described above involves scanning webpages downloaded into a browser to detect html forms (e.g. using an appropriate browser plugin). This might involve, for example, parsing the Document Object Model (DOM) of a webpage, looking for occurrences of 'form' objects and extracting the 'action' attribute from those objects. This attribute contains the submission URL. If detected, the URL associated with the "action" parameter is extracted, and a query sent to the anti-virus provider server. Separate queries can be sent for each submit URL, or multiple URLs can be rolled into a single query. Similarly, one or more responses can be returned by the server. According to this approach, a user can be warned of a potential threat at an early stage, potentially before the webpage is rendered and displayed in the browser window. The embodiments of the invention described above are able to detect threats when entering and submitting data into any webpage containing a form. They are particularly effective in combating XSS attacks during which a legitimate URL is likely to appear in the web browser's address line. It will be appreciated by the person of skill in the art that various modifications may be made to the above described embodiments without departing from the scope of the present invention. For example, rather than sending the query containing the destination URL to a remote server, the web browser plugin may submit this to a local held database and associated query engine. This database may receive regular updates from a service provider, e.g. pushed to it over the Internet.

Claims

1. A method of controlling the sending of sensitive electronic data from a client terminal to a peer over the Internet, the client terminal implementing a web browser for displaying and interacting with webpages, the method comprising:

at the client terminal, identifying a URL associated with an html form tag of a webpage;

querying a reputation database in order to obtain a rating for the URL; and in dependence upon the rating, blocking the sending of data entered into the field(s) of the form over the Internet and/or displaying a warning to the user.

2. A method according to claim 1 , said step of identifying a URL comprising parsing html code of said webpage to identify a form tag and an associated URL.

3. A method according to claim 1 , said step of identifying a URL comprising intercepting and parsing outgoing http data to identify the URL.

4. A method according to any one of the preceding claims, wherein said steps of identifying, querying, blocking, and displaying are carried out by a web browser plugin.

5. A method according to any one of the preceding claims, said step of querying a reputation database in order to obtain a rating for the URL comprising formulating a query at the client terminal containing said URL and sending that query, across the Internet, to a reputation server, and, upon receipt of the query at the rating server determining a rating for the URL and sending a response containing the rating to the client terminal.

6. A method according to any one of the preceding claims, said step of querying a reputation database in order to obtain a rating for the URL comprising querying a rating database maintained at the client terminal.

7. A computer program for use with a computer provided with a web browser for displaying and interacting with webpages, the computer program causing the computer to:

identify a URL associated with an html form tag of a webpage;

query a reputation database in order to obtain a rating for the URL; and in dependence upon the rating, block the sending of data entered into the field(s) of the form over the Internet and/or display a warning to the user.

8. A computer program according to claim 8, the computer program being implemented as a web browser plugin.

9. A computer storage medium having stored thereon a computer program according to claim 7 or 8.

10. A client terminal comprising a computer storage medium according to claim 9.