Editing JavaScript (section)

== Security ==
{{See also|Browser security}}
JavaScript and the [[Document Object Model|DOM]] provide the potential for malicious authors to deliver scripts to run on a client computer via the Web. Browser authors minimize this risk using two restrictions. First, scripts run in a [[Sandbox (computer security)|sandbox]] in which they can only perform Web-related actions, not general-purpose programming tasks like creating files. Second, scripts are constrained by the [[same-origin policy]]: scripts from one website do not have access to information such as usernames, passwords, or cookies sent to another site. Most JavaScript-related security bugs are breaches of either the same origin policy or the sandbox.

There are subsets of general JavaScript—ADsafe, Secure ECMAScript (SES)—that provide greater levels of security, especially on code created by third parties (such as advertisements).<ref>{{cite web | url=https://www.adsafe.org/ | title=Making JavaScript Safe for Advertising | publisher=ADsafe | access-date=2021-05-08 | archive-date=2021-07-06 | archive-url=https://web.archive.org/web/20210706153324/https://www.adsafe.org/ | url-status=live }}</ref><ref>{{cite web | url=https://code.google.com/p/es-lab/wiki/SecureEcmaScript | title=Secure ECMA Script (SES) | access-date=May 26, 2013 | archive-date=May 15, 2013 | archive-url=https://web.archive.org/web/20130515073412/https://code.google.com/p/es-lab/wiki/SecureEcmaScript | url-status=live }}</ref> Closure Toolkit is another project for safe embedding and isolation of third-party JavaScript and HTML.<ref>{{cite web|title=Google Caja Project|url=https://developers.google.com/caja/|url-status=live|website=[[Google]]|access-date=2021-07-09|archive-date=2021-01-22|archive-url=https://web.archive.org/web/20210122083321/https://developers.google.com/caja/}}</ref>

[[Content Security Policy]] is the main intended method of ensuring that only trusted code is executed on a Web page.

=== Cross-site scripting ===
{{Main|Cross-site scripting}}

A common JavaScript-related security problem is [[cross-site scripting]] (XSS), a violation of the [[same-origin policy]]. XSS vulnerabilities occur when an attacker can cause a target Website, such as an online banking website, to include a malicious script in the webpage presented to a victim. The script in this example can then access the banking application with the privileges of the victim, potentially disclosing secret information or transferring money without the victim's authorization. One important solution to XSS vulnerabilities is [[HTML sanitization]].

Some browsers include partial protection against ''reflected'' XSS attacks, in which the attacker provides a URL including malicious script. However, even users of those browsers are vulnerable to other XSS attacks, such as those where the malicious code is stored in a database. Only correct design of Web applications on the server-side can fully prevent XSS.

XSS vulnerabilities can also occur because of implementation mistakes by browser authors.<ref>{{cite web |url=https://www.mozillazine.org/talkback.html?article=4392 |title=Mozilla Cross-Site Scripting Vulnerability Reported and Fixed&nbsp;– MozillaZine Talkback |website=Mozillazine.org |access-date=February 24, 2017 |archive-date=July 21, 2011 |archive-url=https://web.archive.org/web/20110721230916/http://www.mozillazine.org/talkback.html?article=4392 |url-status=live }}</ref>

=== Cross-site request forgery ===
{{Main|Cross-site request forgery}}

Another cross-site vulnerability is [[cross-site request forgery]] (CSRF). In CSRF, code on an attacker's site tricks the victim's browser into taking actions the user did not intend at a target site (like transferring money at a bank). When target sites rely solely on cookies for request authentication, requests originating from code on the attacker's site can carry the same valid login credentials of the initiating user. In general, the solution to CSRF is to require an authentication value in a hidden form field, and not only in the cookies, to authenticate any request that might have lasting effects. Checking the HTTP Referrer header can also help.

"JavaScript hijacking" is a type of CSRF attack in which a <code><nowiki><script></nowiki></code> tag on an attacker's site exploits a page on the victim's site that returns private information such as [[JSON]] or JavaScript. Possible solutions include:

* requiring an authentication token in the [[POST (HTTP)|POST]] and [[GET (HTTP)|GET]] parameters for any response that returns private information.

=== Misplaced trust in the client ===
Developers of client-server applications must recognize that untrusted clients may be under the control of attackers. The author of an application should not assume that their JavaScript code will run as intended (or at all) because any secret embedded in the code could be extracted by a determined adversary. Some implications are:
* Website authors cannot perfectly conceal how their JavaScript operates because the raw source code must be sent to the client. The code can be [[obfuscated code|obfuscated]], but obfuscation can be reverse-engineered.
* JavaScript form validation only provides convenience for users, not security. If a site verifies that the user agreed to its terms of service, or filters invalid characters out of fields that should only contain numbers, it must do so on the server, not only the client.
* Scripts can be selectively disabled, so JavaScript cannot be relied on to prevent operations such as right-clicking on an image to save it.<ref>{{cite web |last1=Kottelin |first1=Thor |title=Right-click "protection"? Forget about it |url=https://blog.anta.net/2008/06/17/right-click-%E2%80%9Cprotection%E2%80%9D-forget-about-it/ |website=blog.anta.net |access-date=28 July 2022 |archive-url=https://web.archive.org/web/20110809195359/https://blog.anta.net/2008/06/17/right-click-%E2%80%9Cprotection%E2%80%9D-forget-about-it/ |archive-date=9 August 2011 |date=17 June 2008}}</ref>
* It is considered very bad practice to embed sensitive information such as passwords in JavaScript because it can be extracted by an attacker.<ref>{{cite web |last1=Rehorik |first1=Jan |title=Why You Should Never Put Sensitive Data in Your JavaScript |url=https://www.serviceobjects.com/blog/why-you-should-never-put-sensitive-data-in-your-javascript/ |website=ServiceObjects Blog |date=29 November 2016 |publisher=ServiceObjects |access-date=June 3, 2019 |archive-date=June 3, 2019 |archive-url=https://web.archive.org/web/20190603142957/https://www.serviceobjects.com/blog/why-you-should-never-put-sensitive-data-in-your-javascript/ |url-status=live }}</ref>
* [[Prototype pollution]] is a runtime vulnerability in which attackers can overwrite arbitrary properties in an object's prototype.

=== Misplaced trust in developers ===
Package management systems such as [[npm (software)|npm]] and Bower are popular with JavaScript developers. Such systems allow a developer to easily manage their program's dependencies upon other developers' program libraries. Developers trust that the maintainers of the libraries will keep them secure and up to date, but that is not always the case. A vulnerability has emerged because of this blind trust. Relied-upon libraries can have new releases that cause bugs or vulnerabilities to appear in all programs that rely upon the libraries. Inversely, a library can go unpatched with known vulnerabilities out in the wild. In a study done looking over a sample of 133,000 websites, researchers found 37% of the websites included a library with at least one known vulnerability.<ref name="jslibs">{{citation |last1=Lauinger |first1=Tobias |last2=Chaabane |first2=Abdelberi |last3=Arshad |first3=Sajjad |last4=Robertson |first4=William |last5=Wilson |first5=Christo |last6=Kirda |first6=Engin |title=Thou Shalt Not Depend on Me: Analysing the Use of Outdated JavaScript Libraries on the Web |url=https://www.ccs.neu.edu/home/arshad/publications/ndss2017jslibs.pdf |website=Northeastern University |access-date=28 July 2022 |archive-url=https://web.archive.org/web/20170329045344/https://www.ccs.neu.edu/home/arshad/publications/ndss2017jslibs.pdf |archive-date=29 March 2017 |doi = 10.14722/ndss.2017.23414 |date = December 21, 2016|arxiv=1811.00918 |isbn=978-1-891562-46-4 |s2cid=17885720 |url-status=dead}}</ref> "The median lag between the oldest library version used on each website and the newest available version of that library is 1,177 days in ALEXA, and development of some libraries still in active use ceased years ago."<ref name="jslibs" /> Another possibility is that the maintainer of a library may remove the library entirely. This occurred in March 2016 when Azer Koçulu removed his repository from npm. This caused tens of thousands of programs and websites depending upon his libraries to break.<ref>{{cite news |work=Quartz |url=https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/ |title=How one programmer broke the internet by deleting a tiny piece of code |first=Keith |last=Collins |date=March 27, 2016 |access-date=February 22, 2017 |archive-date=February 22, 2017 |archive-url=https://web.archive.org/web/20170222200836/https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/ |url-status=live }}</ref><ref>SC Magazine UK, [https://www.scmagazineuk.com/developers-11-lines-of-deleted-code-breaks-the-internet/article/532050/ Developer's 11 lines of deleted code 'breaks the internet'] {{Webarchive|url=https://web.archive.org/web/20170223041434/https://www.scmagazineuk.com/developers-11-lines-of-deleted-code-breaks-the-internet/article/532050/ |date=February 23, 2017 }}</ref>

=== Browser and plugin coding errors ===
{{Further|Buffer overflow}}
JavaScript provides an interface to a wide range of browser capabilities, some of which may have flaws such as [[buffer overflow]]s. These flaws can allow attackers to write scripts that would run any code they wish on the user's system. This code is not by any means limited to another JavaScript application. For example, a buffer overrun exploit can allow an attacker to gain access to the operating system's [[API]] with superuser privileges.

These flaws have affected major browsers including Firefox,<ref>Mozilla Corporation, [https://www.mozilla.org/security/announce/2006/mfsa2006-38.html Buffer overflow in crypto.signText()] {{Webarchive|url=https://web.archive.org/web/20140604014705/https://www.mozilla.org/security/announce/2006/mfsa2006-38.html |date=2014-06-04 }}</ref> Internet Explorer,<ref>{{cite web|last1=Festa |first1=Paul |title=Buffer-overflow bug in IE |url=https://news.com.com/2100-1001-214620.html |archive-url=https://web.archive.org/web/20021225190522/https://news.com.com/2100-1001-214620.html |url-status=dead |archive-date=December 25, 2002 |website=[[CNET]] |date=August 19, 1998 }}</ref> and Safari.<ref>SecurityTracker.com, [https://securitytracker.com/alerts/2006/Mar/1015713.html Apple Safari JavaScript Buffer Overflow Lets Remote Users Execute Arbitrary Code and HTTP Redirect Bug Lets Remote Users Access Files] {{Webarchive|url=https://web.archive.org/web/20100218102849/https://securitytracker.com/alerts/2006/Mar/1015713.html |date=2010-02-18 }}</ref>

Plugins, such as video players, [[Adobe Flash#Flash client security|Adobe Flash]], and the wide range of [[ActiveX]] controls enabled by default in Microsoft Internet Explorer, may also have flaws exploitable via JavaScript (such flaws have been exploited in the past).<ref>SecurityFocus, [https://www.securityfocus.com/bid/19030/info Microsoft WebViewFolderIcon ActiveX Control Buffer Overflow Vulnerability] {{Webarchive|url=https://web.archive.org/web/20111011091819/http://www.securityfocus.com/bid/19030/info |date=2011-10-11 }}</ref><ref>Fusion Authority, [https://www.fusionauthority.com/security/3234-macromedia-flash-activex-buffer-overflow.htm Macromedia Flash ActiveX Buffer Overflow] {{webarchive|url=https://web.archive.org/web/20110813160055/https://www.fusionauthority.com/security/3234-macromedia-flash-activex-buffer-overflow.htm |date=August 13, 2011 }}</ref>

In Windows Vista, Microsoft has attempted to contain the risks of bugs such as buffer overflows by running the Internet Explorer process with limited privileges.<ref>{{cite web |url=https://blogs.msdn.com/ie/archive/2006/02/09/528963.aspx |title=Protected Mode in Vista IE7 – IEBlog |website=Blogs.msdn.com |date=February 9, 2006 |access-date=February 24, 2017 |archive-date=January 23, 2010 |archive-url=https://web.archive.org/web/20100123103719/https://blogs.msdn.com/ie/archive/2006/02/09/528963.aspx |url-status=live }}</ref> [[Google Chrome]] similarly confines its page renderers to their own "[[Sandbox (computer security)|sandbox]]".

=== Sandbox implementation errors ===
Web browsers are capable of running JavaScript outside the sandbox, with the privileges necessary to, for example, create or delete files. Such privileges are not intended to be granted to code from the Web.

Incorrectly granting privileges to JavaScript from the Web has played a role in vulnerabilities in both Internet Explorer<ref>US CERT, [https://www.kb.cert.org/vuls/id/713878 Vulnerability Note VU#713878: Microsoft Internet Explorer does not properly validate source of redirected frame] {{Webarchive|url=https://web.archive.org/web/20091030051811/https://www.kb.cert.org/vuls/id/713878/ |date=2009-10-30 }}</ref> and Firefox.<ref>Mozilla Foundation, [https://www.mozilla.org/security/announce/2005/mfsa2005-41.html Mozilla Foundation Security Advisory 2005–41: Privilege escalation via DOM property overrides] {{Webarchive|url=https://web.archive.org/web/20140604014832/https://www.mozilla.org/security/announce/2005/mfsa2005-41.html |date=2014-06-04 }}</ref> In Windows XP Service Pack 2, Microsoft demoted JScript's privileges in Internet Explorer.<ref>{{cite web |last=Andersen |first=Starr |date=2004-08-09 |url=https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-xp/bb457150(v=technet.10) |title=Part 5: Enhanced Browsing Security |department=[[Microsoft TechNet|TechNet]] |website=[[Microsoft Docs]] |series=Changes to Functionality in Windows XP Service Pack 2 |access-date=2021-10-20}}</ref>

[[Microsoft Windows]] allows JavaScript source files on a computer's hard drive to be launched as general-purpose, non-sandboxed programs (see: [[Windows Script Host]]). This makes JavaScript (like [[VBScript]]) a theoretically viable vector for a [[Trojan horse (computing)|Trojan horse]], although JavaScript Trojan horses are uncommon in practice.<ref>For one example of a rare JavaScript Trojan Horse, see Symantec Corporation, [https://www.symantec.com/security_response/writeup.jsp?docid=2003-100111-0931-99 JS.Seeker.K] {{Webarchive|url=https://web.archive.org/web/20110913210848/http://www.symantec.com/security_response/writeup.jsp?docid=2003-100111-0931-99 |date=2011-09-13 }}</ref>{{failed verification|date=March 2017}}

=== Hardware vulnerabilities ===
In 2015, a JavaScript-based proof-of-concept implementation of a [[rowhammer]] attack was described in a paper by security researchers.<ref>{{cite arXiv | eprint = 1507.06955 | title = Rowhammer.js: A Remote Software-Induced Fault Attack in JavaScript | date = July 24, 2015 | last1 = Gruss | first1 = Daniel | last2 = Maurice | first2 = Clémentine | last3 = Mangard | first3 = Stefan | class = cs.CR }}</ref><ref>{{cite news |work=Motherboard |publisher=[[Vice (magazine)|Vice]] |title=Rowhammer.js Is the Most Ingenious Hack I've Ever Seen |first=Alix |last=Jean-Pharuns |date=July 30, 2015 |url=https://www.vice.com/en/article/rowhammerjs-is-the-most-ingenious-hack-ive-ever-seen/ |access-date=January 26, 2018 |archive-date=January 27, 2018 |archive-url=https://web.archive.org/web/20180127084042/https://motherboard.vice.com/en_us/article/9akpwz/rowhammerjs-is-the-most-ingenious-hack-ive-ever-seen |url-status=live }}</ref><ref>{{cite web|website=[[Ars Technica]]|title=DRAM 'Bitflipping' exploit for attacking PCs: Just add JavaScript|first=Dan|last=Goodin|date=August 4, 2015|url=https://arstechnica.com/information-technology/2015/08/dram-bitflipping-exploit-for-attacking-pcs-just-add-javascript/|access-date=January 26, 2018|archive-date=January 27, 2018|archive-url=https://web.archive.org/web/20180127143154/https://arstechnica.com/information-technology/2015/08/dram-bitflipping-exploit-for-attacking-pcs-just-add-javascript/|url-status=live}}</ref><ref>{{cite web | url = https://www.slate.com/articles/technology/bitwise/2015/07/rowhammer_security_exploit_why_a_new_security_attack_is_truly_terrifying.html | title = Rowhammer security exploit: Why a new security attack is truly terrifying | date = July 28, 2015 | access-date = July 29, 2015 | first = David | last = Auerbach | author-link = David Auerbach | website = slate.com | archive-date = July 30, 2015 | archive-url = https://web.archive.org/web/20150730004023/https://www.slate.com/articles/technology/bitwise/2015/07/rowhammer_security_exploit_why_a_new_security_attack_is_truly_terrifying.html | url-status = live }}</ref>

In 2017, a JavaScript-based attack via browser was demonstrated that could bypass [[Address space layout randomization|ASLR]]. It is called "ASLR⊕Cache" or AnC.<ref>[https://www.vusec.net/projects/anc/ AnC] {{Webarchive|url=https://web.archive.org/web/20170316055626/https://www.vusec.net/projects/anc/ |date=2017-03-16 }} VUSec, 2017</ref><ref>[https://arstechnica.com/security/2017/02/new-aslr-busting-javascript-is-about-to-make-drive-by-exploits-much-nastier/ New ASLR-busting JavaScript is about to make drive-by exploits much nastier] {{Webarchive|url=https://web.archive.org/web/20170316024419/https://arstechnica.com/security/2017/02/new-aslr-busting-javascript-is-about-to-make-drive-by-exploits-much-nastier/ |date=2017-03-16 }} Ars Technica, 2017</ref>

In 2018, the paper that announced the [[Spectre (security vulnerability)|Spectre]] attacks against Speculative Execution in Intel and other processors included a JavaScript implementation.<ref>[https://spectreattack.com/spectre.pdf Spectre Attack] {{Webarchive|url=https://web.archive.org/web/20180103225843/https://spectreattack.com/spectre.pdf |date=2018-01-03 }} Spectre Attack</ref>