While going over these javascript design vulnerabilities we have to be aware of the top web security vulnerabilities, a nice list is being given here by Gergely Kalman: https://www.toptal.com/security/10-most-common-web-security-vulnerabilities
When you read this you will understand why we do the scans we do. Analyze the HTTP response headers, see where code is same origin, e.g. SRI Hash Website Scan, Safer Chrome Security Report, look for Cloaking and hidden iFrames, Tracker SSL insecure IDs tracking, retirable jQuery scans, CMS insecurity scans, SSL tests, DNS tests, Website and nameserver misconfiguration test (asafaweb scan etc.). DOM XSS vulnerability scan, Javascript Unpacker Scan, and various other scans.
So we have to filter untrusted input, broken authentication and involved threats, input sanitization problem (XSS), store data internally and set session variable (undefined functions and variables always form a threat vector). Security misconfigurations like user enumeration set by default and directory listing, server header info proliferation, excessive services and outdated or even left software running etc. Non-HTTPS content, lack of PFS, requests should not be able to alter the resource requested. Do not use vulnerable components (plug-ins), header injection can be rather bad,
JavaScript sources are functions or DOM properties that can be influenced by the user. Vulnerable JavaScript sources that can be exploited for a DOM-based attack include the following:
Location-based, such as location, location.href, document.URL and so on.
Client-side storage based. For instance, it could be document.cookies, sessionStorage and localStorage.
Navigation-based, such as navigation.referrer, window.name, history et al.
Cross-domain functions. See: http://www.domxssscanner.com/
Some common exploitable JavaScript sinks:
Execution-based, such as eval(), Function(), setTimeout(), setInterval() and so on.
URL-based, for instance location and location.assign().
HTML-based, such as document.write(), HTML elements and attributes.
XHR calls, postMessage, client-side storage and other JavaScript variables.
postMessage is a JavaScript function under HTML5 that facilitates communication across iframes, i.e. two iframes loaded from separate domains on the same page or between the page and an iframe within it. This communication is entirely client-side. If postMessage restrictions are set loosely, it could result in invalidated malicious data being sent across iframes or a potential data leak scenario making it possible to perform data extraction across sites. The white-list paradigm applies here as well.
With HTML5, client-side storage mechanisms have gone beyond the cookie with newer options such as localStorage, Web SQL and IndexDB. Storage of sensitive data on the client side using these mechanisms fosters a huge security risk, bigger than cookies ever posed.
Quote taken from author: Lavakumar Kuppan on HTML5 security Check using: https://html5.validator.nu/
polonus (volunteer website security analyst and website error-hunter)
P.S. Also learn about Bug Patterns: https://find-sec-bugs.github.io/bugs.htm Created by Philippe Arteau
and http://alistapart.com/blog/post/pattern-library-security-vulnerability from Mat Marquis
blog has a vulnerability by itself: Pattern Library Security Vulnerability · An A L… padlock icon
alistapart.com
Alerts (1)
Insecure login (1)
Password will be transmited in clear to http://alistapart.com/?ACT=159
Infos (1)
Encryption (HTTPS) (1)
Communication is NOT encrypted Safer Chrome Security Report.
Damian
