有人說大腦是個不設防的城市，因此務須警醒『人』『言』，切莫偏『信』的好。早在網景推出『JavaScript』網頁手稿語言︰

JavaScript，一種高階程式語言，通過解釋執行，是一門動態型別，物件導向（基於原型）的直譯語言^[4]。它已經由ECMA（歐洲電腦製造商協會）通過ECMAScript實現語言的標準化^[4]。它被世界上的絕大多數網站所使用，也被世界主流瀏覽器（Chrome、IE、FireFox、Safari、Opera）支援。JavaScript是一門基於原型、函式先行的語言^[5]，是一門多範式的語言，它支援物件導向編程，指令式編程，以及函數語言程式設計。它提供語法來操控文字，陣列，日期以及正規表示式等，不支援I/O，比如網路，儲存和圖形等，但這些都可以由它的宿主環境提供支援。

雖然JavaScript與Java這門語言不管是在名字上，或是在語法上都有很多相似性，但這兩門程式語言從設計之初就有很大的不同，JavaScript的語言設計主要受到了Self（一種原型程式設計語言）和Scheme（一門函數語言程式設計語言）的影響^[5]。在語法結構上它又與C語言有很多相似（例如if條件語句、while迴圈、switch語句、do-while迴圈等）^[6]。

在用戶端，JavaScript在傳統意義上被實現為一種解釋語言，但在最近，它已經可以被即時編譯（JIT）執行。隨著最新的HTML5和CSS3語言標準的推行它還可用於遊戲、桌面和行動應用程式的開發和在伺服器端網路環境執行，如Node.js。

 

時，就已經知道可能的資安疑慮。所以瀏覽器才將 JavaScript 程式放在

沙盒 (電腦安全)

在計算機安全領域，沙盒（英語：sandbox，又譯為沙箱）是一種安全機制，為執行中的程式提供的隔離環境。通常是作為一些來源不可信、具破壞力或無法判定程式意圖的程式提供實驗之用^[1]。

沙盒通常嚴格控制其中的程式所能存取的資源，比如，沙盒可以提供用後即回收的磁碟及記憶體空間。在沙盒中，網路存取、對真實系統的存取、對輸入裝置的讀取通常被禁止或是嚴格限制。從這個角度來說，沙盒屬於虛擬化的一種。

沙盒中的所有改動對作業系統不會造成任何損失。通常，這種技術被電腦技術人員廣泛用於測試可能帶毒的程式或是其他的惡意代碼^[2]。

 

裡執行！這樣不就安全了嗎？殊不知由於廠商追求產品特色，大開便門；使用者以為安全，隨意打開權限；加上許多其他原由︰

Security

JavaScript and the DOM provide the potential for malicious authors to deliver scripts to run on a client computer via the Web. Browser authors contain this risk using two restrictions. First, scripts run in a 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 Web site 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 level of security, especially on code created by third parties (such as advertisements).^[57][58] Caja is another project for safe embedding and isolation of third-party JavaScript and HTML.

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

Cross-site vulnerabilities

A common JavaScript-related security problem is cross-site scripting (XSS), a violation of the same-origin policy. XSS vulnerabilities occur when an attacker is able to cause a target Web site, 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. A solution to XSS vulnerabilities is to use HTML escaping whenever displaying untrusted data.

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.^[59]

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 didn’t intend at a target site (like transferring money at a bank). It works because, if the target site relies only on cookies to authenticate requests, then requests initiated by code on the attacker’s site will carry the same legitimate login credentials as requests initiated by the 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 <script> 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 and 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 application author cannot assume that his 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:

• Web site authors cannot perfectly conceal how their JavaScript operates because the raw source code must be sent to the client. The code can be 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 can’t be relied on to prevent operations such as right-clicking on an image to save it.^[60]
• It is extremely bad practice to embed sensitive information such as passwords in JavaScript because it can be extracted by an attacker.

Misplaced trust in developers

Package management systems such as NPM and Bower are popular with JavaScript developers. Such systems allow a developer to easily manage their program’s dependencies upon other developer’s program libraries. Developers trust that the maintainers of the libraries will keep it 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 release an update that causes bugs or vulnerabilities to appear in all programs that rely upon the library. Inversely, a library can go unpatched with known vulnerabilities out in the wild. In a study done looking over a sample of 133k websites, researchers found 37% of the websites included a library with at-least one known vulnerability.^[61] “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.”^[61] 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 all tens of thousands of programs and websites depending upon his libraries to break.^[62][63]

Browser and plugin coding errors

JavaScript provides an interface to a wide range of browser capabilities, some of which may have flaws such as buffer overflows. 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,^[64] Internet Explorer,^[65] and Safari.^[66]

Plugins, such as video players, 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).^[67][68]

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.^[69] Google Chrome similarly confines its page renderers to their own “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. Of course, such privileges aren’t meant 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^[70] and Firefox.^[71] In Windows XP Service Pack 2, Microsoft demoted JScript’s privileges in Internet Explorer.^[72]

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, although JavaScript Trojan horses are uncommon in practice.^{[73][not in citation given]}

Hardware vulnerabilities

In 2017 a JavaScript based attack via browser was demonstrated that could bypass ASLR. It’s called “ASLR⊕Cache” or AnC.^[74][75]

 

造成的資安問題或許更勝於『電腦病毒』的哩？？

電腦病毒，或稱計算機病毒。是一種在人為或非人為的情況下產生的、在用戶不知情或未批准下，能自我複製或運行的電腦程式；電腦病毒往往會影響受感染電腦的正常運作，或是被控制而不自知，也有電腦正常運作僅盜竊資料等用戶非自發啟動的行為。

 

此所以跨網攻擊日漸猖狂矣！！

跨網站指令碼（Cross-site scripting，通常簡稱為XSS）是一種網站應用程式的安全漏洞攻擊，是代碼注入的一種。它允許惡意使用者將程式碼注入到網頁上，其他使用者在觀看網頁時就會受到影響。這類攻擊通常包含了HTML以及使用者端腳本語言。

XSS攻擊通常指的是通過利用網頁開發時留下的漏洞，通過巧妙的方法注入惡意指令代碼到網頁，使用戶載入並執行攻擊者惡意製造的網頁程式。這些惡意網頁程式通常是JavaScript，但實際上也可以包括Java，VBScript，ActiveX，Flash或者甚至是普通的HTML。攻擊成功後，攻擊者可能得到更高的權限（如執行一些操作）、私密網頁內容、對談和cookie等各種內容。

 

想必讀者自可推知『雲端應用』潛在風險耶！！？？