A New Security Model for Web Browser Local Storage

In recent years, the web browser has taken over many roles of the traditional operating system, such as acting as a host platform for web applications. Web browser storage, where the web applications can save data locally was one of the new functionalities added in HTML5. However, web functionality has increased significantly since HTML5 was introduced. As web functionality increased, so did the threats facing web users. One of the most prevalent threats was the user’s privacy violations. This study examines the existing security issues related to the usage of web browser storage and proposes a new model to secure the data saved in the browser’s storage. The model was designed and implemented as a web browser extension to secure the saved data. The model was experimentally demonstrated and the result was evaluated.


I. INTRODUCTION
The internet and its applications have critically influenced us and becoming the main part of daily life. The internet provides information and opportunities, which were not accessible previously. The digital population has risen in the last few years; it reached 4.087 billion users in April 2018 [1]. With an increase in dependency on the internet, the importance of privacy protection has become significant.
When browsing, users expose themselves and their personal information to several threats, such as malware or phishing, which directly disrupt privacy [2]. A user's profile has been the target of many attacks. There are different reasons for an attack on a user's profile, including identifying the characteristics of users to meet their requirements or selling this information for surveillance or advertising [3]. Over the years, many technologies have been utilized to track a user's profile; the most well-known is cookies.
HTML is a standard language used to develop web applications. HTML5 is the latest version of HTML that the W3C standard introduced as a written language for web pages and associated applications (APIs). HTML5 brings a set of new advancements to the browser, which didn't exist previously, including enhanced XMLHttpRequest (XHR) and webSocket [4]. Web-based applications can be run offline via local storage, meaning the data will be saved in the user-side storage and it can be accessed without having to connect to the network [5]. User -side storage as indexed database APIs, web SQL databases, and web storage revolutionized the web and minimized the differences between native applications and web-based applications. Consequently, network connections' lack of effectivity on the server-side and the visual uncertainty affected by refreshes could be avoided. Besides, HTML5 offers functionality that can be utilized by web-based applications on any platform and on different browsers. Thus, modern web browsers support the plurality of new HTML5 features [6].
In spite of the advantages, user-side storage did not come without a price. The data saved by user-side storage is unencrypted, so users may experience privacy violations, such as a tracking vector. The literature in [7], [8], [9] revealed that the data created by web applications and saved in user-side storage cannot be completely deleted, even when the users tried. Thus, there are dangerous privacy implications, such as the details of a user's bank account or credit cards.
Previous studies to protect user-side storage were rather limited. This study proposes a new model that aims to protect the user's privacy. The proposed security model, which was based on the JavaScript encryption library (JSEL), was implemented as a web browser extension. The browser extension offered complete security protection, as the data were saved in encrypted form.
The remainder of the paper is arranged as follows. The theoretical background is presented in Section 2. Section 3 presents an overview of possible technical attacks associated with local browser storage and the current security solutions. Section 4 presents a new security model for browser-based storage. Related works are discussed in Section 5. The experimental study and the evaluation are presented in Sections 6 and 7, respectively. Finally, the conclusions and future work are presented in Section 8.

II. BACKGROUND
The most famous user-side database is HTTP cookies. Cookies are small packets of data (normally 4KB) sent from websites servers to users through HTTP headers or by utilizing user-side scripting. Cookies saved in a user's browser are on the user's machine. Every cookie is related to a source, i.e., a port number, HTTP protocols, and the hostname. It based on a security mechanism termed same-origin policy (SOP). Website servers use cookies to remember a user's stateful information or to trace the browsing activity of the user. Security and privacy are the major challenges, as an attacker can steal data from cookies [10].
Web storage provides a way for web applications to save data locally in the user's browser without affecting website performance and provides more storage capacity than cookies. Depending on the user's browser, web storage capacity can be anywhere from 5MB to 25MB [11]. Web storage saves data in key/value pairs in the browser, and there two types. First is session storage data, which will be lost when the user browser is closed. Second is local storage data that are maintained even when the browser is closed [12]. Web storage is dependent on user-side scripting, such that the web application can retrieve locally stored data by utilizing a user-side JavaScript API even when the user's browser is disconnected [11]. Besides, web storage differs from cookies, since the saved data cannot be transferred through HTTP headers. The security policy of web storage is the same as for cookies since each source is assigned to a unique web storage object. Therefore, using web storage on websites that do not support HTTPS or that use hostname sharing is not recommended [6].
A WebSQL database is another way for web applications to save huge amounts of information in the user's browser, which can be queried by using standard SQL syntax. A WebSQL database is similar to Google Gears, and both depend on SQLite [13]. The main weakness of a WebSQL database is that it is not supported by W3C, and many browsers, for example, Mozilla, have decided to stop supporting WebSQL databases. Despite the W3C decision, three main browser vendors (Opera, Safari, and Chrome) still support WebSQL databases [11].
Indexed database API (Indexed DB) is a transactional database system that came from the W3C specification in 2009. Indexed DB is a substitute for the deprecated WebSQL database [14]. Indexed DB has the same accessing mechanism as web storage, but the scale and structure of the saved data are different. Web storage saves data in key/value pairs and is suitable when the dataset is simple, whereas Indexed DB allows for a large amount of structured data to be saved in storage [15].
Compared to SQL-based relational database management system (RDBMS), which uses tables to save data, Indexed DB is an object-oriented database. Indexed DB allows for objects to be saved/retrieved with keys [16]. Web applications can only access and operate saved structured data through the API provided by Indexed DB. Indexed DB is built on a transactional database mode and is typically key-value asynchronous storage. It provides rapid access to a lot of organized information [14]. In contrast, the security mechanism for Indexed DB is no different than web storage. The Indexed DB security mechanism is based on the principles of the SOP [13].

III. SECURITY ISSUES
With the new functionalities of HTML5, which increased the accessibility to a user's computer resources, including offline caching and local storage, new security issues arose. Most web browser security methods were not upgraded to the new technologies of HTML5. The only browser security method in place against possible risks was SOP [9]. SOP links the saved information to a specific domain, so the information can only be retrieved from the original domain. When SOP is applied, the browser tests the port number, name of host, and protocol against the source record of the saved data [2].
HTML5 has numerous new modules, such as "XMLHttpRequest (XHR), the document object model (DOM), and cross-origin resource sharing (CORS)." HTML5 brought new technologies, such as local storage, web Socket, and enhanced XHR. With these technologies and modules, it has improved the surface of the attack and added new risks to the end-user, which means that the SOP will not help [2]. The weaknesses of SOP led to many aggressions, such as "crosssite scripting (XSS), cross-site request forgeries (CSRF), cross-origin resource sharing (CORS) attacks, social engineering, and physical access" [17].
CORS is a technique that lets JavaScript make an XHR request from other domains outside the original domain. XHR is used by JavaScript to perform transfers between the server and the user. Cross-domain requests are normally prevented by web browsers, so CORS adds additional information to HTTP headers to permit the request [17]. A CORS technique allows for several domains (cross-domain requests) between the user and the server. However, hackers can make cross-site request forgeries by bypassing SOP and creating "crossdomain connections" to permit the deployment of a CORS attack vector [3].
XSS is one the most common attacks in a web-based application. Based on the open software security community (OWASP) list, XSS ranks third place in OWASP list [18]. XSS is a security weakness, where malicious code (generally JavaScript) is injected into a web-based application and is comprised of dynamic content sent to a victim's browser. The victim's browser cannot identify that the script is infected, and will execute the malicious script without being validated because it appears to have arrived from a trusted source. The malicious script can change or transmit session tokens, cookies, or any information via the victim's browser [19]. There are many techniques to prevent XSS attacks, such as encoding output (stop executing URL links that include binary encoded characters), filtering (the input data is filtered before it saved in the database), and authenticating user input (checking the format of the user) [6].
Social engineering is a way of fooling and cheating users so that personal data is shared, such as bank accounts or passwords. The hackers can install malicious code to access data by controlling the user's computer. Social engineering techniques are easier than other hacking techniques and can include calling by phone, sending an email, and real-life chats. An email from a known sender is a popular example of a social engineering technique. Hackers send an email message with a link to the victim contact list members. The link may CSRF is also known as session riding or a one-click attack. An attacker could trick the victim into unintentionally performing an undesirable action in the web application [21]. CSRF is normally performed with the assistance of social engineering techniques. As the victim is currently authenticated by the web application, it is difficult for the server to differentiate between legal requests and fake requests [15]. CSRF attacks can harm both users and businesses. It can result in damaged user relationships, illegal money transfers, changed passwords, and stealing of data, including the session cookies [17].
Physical access is another security problem that occurs when the attacker has access to the user's computer. When this happens, the saved data and even the deleted data can be stolen. Recovering deleted data is primarily concerned for developers. The experiment conducted by Shahryar [22] showed that the location of the deleted data within a database was still physically reserved. The deleted data was only marked as deleted ,but the data existed in storage and could be retrieved with forensic tools. In most web browsers, the nondeleted data will not be overwritten by newly saved data [9]. The data is saved in storage as non-encrypted, so it is not protected and presents a possible security issue. Encryption will prevent data from being attacked. User-side encryption is important since it offers a security mechanism for saved data and blocks unauthorized persons from stealing the user's data. Unfortunately, user-side encryption is not yet mature. In the next suction, this study proposes a new encryption model to protect a user's data.

IV. SECURITY MODEL
This study proposes a new security model to address issues caused by saving data in an unsafe manner. In the proposed model, an additional layer was added among the web browser storage and the web browser itself. The model contains a new algorithmic framework for improving security against threats. The model uses JavaScript encryption library, which was applied to the web browser as "an extension." The extension was located at the top of the web browser storage, such that whenever writing or reading information, it is encrypted.
Encryption/decryption can be implemented inside browsers via the" JavaScript crypto library." There are a small number of JavaScript encryption libraries that may be applied to encrypt data in the client's browser, such as WebCryptoAPI, PolyCrypt, Cryptos, Jscrypto, and SJCL [21]. Many factors affect the selected encryption library, including library size, hashing functions, key lengths, keyed-hash message authentication codes (HMAC), salt, and availability of multi-platform and multi-browser options [11].
This study selected the Stanford JavaScript crypto library (JSCL) to implement the encryption/decryption on the user's browser. The SJCL library was chosen because it is a secure, small, multi-platform, and powerful library [23]. SJCL uses the advanced encryption standard (AES) to encrypt data at key sizes of 128/192/256 bits. It also uses an HMAC validation code, the SHA256 hash function, OCB and CCM authenticated modes, and the PBKDF2 to strengthen the password. BKDF2 applies a pseudorandom function to the entered password together with a salt value and reiterates the process several times to generate a derived key, which then can be utilized as a crypto key. PBKDF2 verifies each message it sends to avoid any changes. Furthermore, the tests conducted in several browsers on Windows, Linux, and Mac have shown that the SJCL was faster than any existing encryption library [23].
As the browser extension used the SJCL library, the same shared key was applied for both encryption and decryption, which made the data prone to malicious attacks. To overcome the limitations of the SJCL library, the study combined the RSA standard [9] with SJCL library. The combination resulted in a hybrid encryption algorithm comprised of both RSA and AES to guarantee data integrity.
When the browser storage received a request from a web application to save data, the data was encrypted by the proposed browser extension. This ensured that the data was safe and secured against illegal access even if the attacker gained physical access to the machine. The data encryption/decryption steps are as follows:  Get Login: The initial step is to afford a secure log into the system. Web applications can handle this step for the users by using the login process.
 Data Encryption: When a new request from a web application arises to save data in the database, the plain text data (PTORG) is encrypted by the designed extension and a public key (KSJCL) is generated. The KSJCL will be used when the SJCL library encrypting the data. The encrypted data is named ENORG. Simultaneously, when the encryption process is enabled in user-side, the RSA standard is generated. RSA standard is used to encrypt the ENORG by using the private key (PSJCL) to produce a "digital signature."  Data Decryption: When a request from an authorized user to read data from the browser's storage arises, the key (K SJCL) is encrypted using an RSA standard with the requester public key (RKPB). The encrypted key is named (RKEN SJCL). An XML file is then created, including ENORG and RKEN SJCL. Finally, the ENORG is decrypted using KSJCL.
 Deletion of Data: The data in the session storage is safely deleted -that is, it was replaced with zeros. Thus, the deleted data cannot be read again, since the original data was set to zero.
The goal of this study is to protect saved data on clientside databases against illegitimate access. The study had many choices for encryption, but most tended to save encryption keys on the server-side and not on the user-side. One limitation of utilizing the server-side was associated with offline storage, the client won't almost certainly get to the information. Besides, if the webserver is vulnerable to any attack, then the encryption key will be perilous and thus, the www.ijacsa.thesai.org encrypted information will be defenseless against unapproved access from attackers. Also, the W3C recommendation is to save the encryption keys on the client-side [24].
Browser security models depend on an SOP mechanism. However, an SOP mechanism alone is not enough for sophisticated web-based applications' local storage security. The proposed model differs in the security mechanism. Where the browser security models attempt to secure data amongst the user's browser and web-based applications, the proposed model secures data saved in the user's database. Thus, users can visit other websites without worrying about the databases.

V. RELATED WORK
Previous studies regarding securing web browser storage and its effectiveness are still in early stages and are limited. Aggarwal et al. [25] conducted one of the first studies to analyze browsing security vulnerabilities. The results revealed that there was an insufficient implementation of the security mechanism in different web browsers, which pointed to user activities. Additionally, security control for Firefox was proposed, which protected users after private mode was enabled. In 2011, Oh et al. [26] analyzed the log files generated by a web browser, concentrating on search history, timeline analysis, and URL encoding. A Classification of Web Browser Log (CWB) tool was proposed to prove the analysis. Unfortunately, in the experiments, old versions of browsers were used that are currently outdated.
Ohana and Shashidhar [27]studied portable browsers to determine if data still existed after the browser session stopped. Similarly, Said et al. [28] analyzed the RAM in the browser sessions, including authorizations, history, images, and videos. Satvat et al. [29] extended the work by analyzing the file system and the network, which exposed significant contradictions in the browsing implementation that violated a client's privacy. Heule et al. [30]developed a security access control to protect confidential data that could be accessed and used by attackers, focusing on JavaScript extensions in Chrome. In the same manner, Lerner et al. [31] studied JavaScript extensions in Firefox from different perspectives, such as social, safety, and debugging, to determine which may be malicious.
Ruiz et al. [32] concentrated on recovery techniques created during browsing. Experiments within four personal levels showed how the browser could be stopped, namely shutdown, power down, freeze, and kill processes. The results revealed that all levels included user privacy violations in terms of obtaining browsing data. In the same manner, Montasari and Peltola [33] studied both file systems and RAM in different browsers. The results revealed that the most secure browser was Chrome and in second place was Firefox.
A survey conducted by Gao et al. [34] concentrated on awareness from a user's viewpoint. Authors surveyed more than 200 users regarding the security and privacy mechanisms provided by the most common web browsers on smartphone and desktop platforms. The results revealed that better security guarantees were required concerning a user's privacy. Tsalis et al. [35] studied the protection provided by different popular web browsers. A set of web data created in a usual browsing session was used to determine where these data were saved after the session was stopped. The results revealed that the deleted data after the browsing session were discovered straightforward or in a roundabout way in the database. Subsequently, any person who had "physical access" to the user's machine with adequate IT abilities could access these browsing data. In addition, nearly all browsers provided a similar protection level, and only Chrome in the guest mode provided better protection. Belloro and Mylonas [30] investigated the most common user storage methods, namely "Web SQL database, web storage, and indexed database." The outcomes revealed that web storage was the most utilized. Belloro and Mylonas also surveyed whether well-known mobile and desktop browsers that used "indexed database API, web SQL database and web storage" could defend clients from privacy violations. The results showed that the maturity of the security controls was inadequate to avoid privacy violations.

VI. EXPERIMENT
The experiment performed in this study was based on performance.
The study tested the speed of encryption/decryption, which affected the performance of the model. Thus, the study tested the performance on the user-side to prevent the network and server latency impacting the results. The study selected indexed database as a representative for web browser local storage.
Before running the test, the code was executed for a compatibility test in diverse browsers, including Firefox, Google Chrome, Safari, Mozilla, and Opera. The latest Google Chrome browser hosted by a Windows10 server was chosen as the test environment. The server was an HP with Intel I7 8550U, and 8 GB DDR4 RAM. The test executed a small JavaScript by dexie.js, which is a powerful library for an indexed database and it can accelerate performance. Google private mode was used to the grantee that the test was executed without any additional load of scripts or any extension. Fig. 1 show the code used.
The test was performed in steps. The first step was to save the data without encryption (in a standard manner). The second step was to save data with encryption, as seen in Fig. 2. The same password and username were saved with encryption.
The test was executed without any user intervention. JavaScript read the entries of the database, placed the data into the table, and read it as a console output (console.log). All references employed in this study were based on Google performance analysis [17]. Fig. 3 shows the results of the performance test, it shows the top 10 bottom-up of processes that most consuming time.
Because the indexed database is a NoSQL database, the script run time had to be tested independently of the transaction speed of the database. Consequently, the performance test depended on the reading and writing of database entries in a loop. The time was measured before the loop started and after the loop was finished. Finally, the data entries contained "Password + I and User + i" where "I" was the loop counter. The time in milliseconds to insert database entries with and without encryption in Google Chrome is shown in Table I.    VII. EVALUATION Big O notation was used to evaluate the proposed model. It compares the effectiveness of different algorithms by revealing the time that the algorithm took to run. The runtime can be expressed with Big O Notation as how fast the runtime grew relative to the size of the input "n" (denoted O (n)).
AES allows for three diverse key sizes of 128, 192, or 256 bits. The processing required 10 rounds when encrypting with the 128-bit key, 12 rounds for the 192-bit key, and 14 rounds for the 256-bit key. When ciphering with the 128 bit key, all 2 128 keys mixtures must be inspected by decrypting the encrypted text with every one of those values [13].
For decryption and encryption, every round had four functions, excluding the final round with three. Encryption had the following functions: SubByte, ShiftRows, MixColumn, and AddRoundKey. A similar number of round functions were used for decryption, but with the opposite transformation.
The algorithm takes into account the diverse runtime periods with the same inputs, based on the speed of the processor, disk speed, instruction set, and type of compiler. The measured runtime "T (n)" is the amount of primary steps, taking into account that every progression step requires steady time. Since the inner loop iterates, the runtime was computed as: Where n is the size of the input data. Thus, the performance of an algorithm is proportional to the square of n. The study tested the performance impact of including encryption steps to the key-value database of web storage. Fig. 4 shows the results.
The results indicate that the process with encryption steps became slower by 10-40%. Therefore, applying encryption/decryption increased security but decreased response time. The process of encryption/decryption depended on hardware optimization and configuration. Devices with superior processors and greater memory storage sped up the process. AES functionality is now integrated into many processors, which helps to reduce encryption\decryption time. Local browser storage has important advantages, when compared with a server-side database, including fast response, offline usage, and decreased network latency. However, currently, local browser storage is not secure. The main security concern is that data saved locally is unencrypted. The literature confirmed that the unencrypted data was not the only problem facing local browser storage. Data recovery of previously deleted data was another serious problem. Current security methods do not provide adequate security defenses for data saved locally, particularly data that may contain private information.
This study proposed and implemented a new security model for local browser storage. The new model added an additional layer amongst local browser storage and the web browser itself. The model contained an algorithmic framework for improving security against vulnerabilities identified in this study. JSCL was used in the proposed algorithm and was applied to the web browser as an extension. The SJCL library was chosen because SJCL is a secure, small, fast, multiplatform and powerful library for cryptography in JavaScript. The study combined the RSA standard with an SJCL library, which resulted in a hybrid encryption algorithm to guarantee data integrity.
When browser storage received a request from a web application to save data, the data was encrypted by the proposed browser extension. Encrypting data in browser storage kept data from being undermined regardless of whether the attackers acquired physical access to the machine, which may occur if a phone, tablet, or computer is lost or stolen. Although the proposed model has been effectively applied to local browser storage, additional enhancements could be made in the future by extending the performance and security model. For example, a complete security library could be written to utilize diverse JavaScript crypto libraries. Further experiments with different crypto libraries could also be performed to compare the results.