Is it PCI-compliant to serve images (securely) from a different domain? I searched the PCI DSS 2.0 PDF and didn't find any references to it.
Images do not fall under PCI compliance. PCI DSS covers the storing, transmission, and processing of credit card information only. So you can serve your images from any server you like without having any PCI issues.
I take it these images are going to appear on the same page as the credit card entry form? If so as long as they are rendered over SSL, then they cannot be hijacked and additional code rendered in their place.
I would say that it would aid in your compliance to have the images served via SSL regardless of the domain due to the fact that your payment page must be presented in SSL to the end user.
Related
I'm working for a forum owner who allows users to submit hotlinked images from other domains in their posts. If they choose to use an http version of the URL, the otherwise clean page becomes insecure in the eyes of a browser, which some percentage of the time triggers a worried email from certain users.
I can't rewrite the urls, since I can't code against the assumption that future off site images will have https available. For the same reason, I can't use protocol relative src attributes. I'm unwilling to fetch and cache the images on our server just so that they can be served over https, because of the computational expense involved.
What can I do? Is there some piece of HTML syntax or some similar which I can use to tell the browser "This image doesn't matter, and doesn't constitute a security threat"?
This isn't possible. The image may not constitute a security threat but MITM attacks could still lead to images other than the intended one being loaded over the network, and who knows what an attacker may want to supplant that image with. My suggestion would be to pass the annoyance on to your users and tell them they can only use https URLs.
I can't figure out what is difference between MessageChannel and WebSockets?
I need following requirements:
minimize delay
full-duplex
minimum header data length
Are both fullfil this requirements? Which is better?
HTML5 Web Messaging API can be used to communicate between independend pieces of code loaded in the browser (specification calls them "browsing contexts"). For example, if your page contains an <iframe>, and you want to securely communicate between it and the outside code, you might use Web Messaging. Consider this explanation from the Opera dev portal:
Channel messaging is particularly useful for communication across
multiple origins. Consider the following scenario. We have a document
at http://socialsite.example containing content from
http://games.example embedded in one iframe, and content from
http://addressbook.example in another.
Now let’s say that we want to
send a message from our address book site to our games site. We could
use the social site as a proxy. That, however, means the address book
gains the same level of trust as the social site. Our social site
either has to trust every request, or filter them for us.
With channel
messaging, however, http://addressbook.example and
http://games.example can communicate directly.
Web Sockets API can be used to communicate between code loaded in the browser and the server. So it serves a completely different purpose. Since you're mentioning the requirement of low latency and "full-duplex" I assume you mean client-server communication, and so you're looking for a web sockets.
I have been asked to set up some registration forms for clients that will take payments, similar to this site (https://www.martialartstechnologies.com/register?tournamentID=82). I am a reseller for Authorize.net, but I find it hard to sign clients up sometimes after they find out they need to get PCI compliant. I was thinking of creating one site domain that is PCI Compliant and then running each clients registration page in their own personal subdomain. If I do this, will the PCI compliance on the domain become invalid for each subdomain, or will it still be covered?
Only company can be PCI compliant, not a server, a site, a particular script, a domain or subdomain name. Whole infrastructure, including such things as office WiFi networks and cabinet locks is being audited. You can't trick the auditor painting a cabinet in a different color and claiming it is not yours.
Even if you got 1000 domain names - and they are pointed to 1000 servers located in 1000 places all over the Earth - you must list them all for PCI audit and make them all PCI compliant.
Subdomains can be on different servers, so the first question to answer would be 'same or different servers'? If on different servers and handling credit card info, you would need to make each server PCI compliant regardless.
PCI compliance deals with the question of code/infrastructure.
You cannot, as suggested, automatically extend it to sub-domains - even if the main domain is compliant.
Still, if you use the same infrastructure for all sub-domain, you can take care of code related vulnerabilities or just envelope the whole structure in a PCI DDS compliant WAF (I suggest Cloud PCI DDS compliant WAF to cut costs).
What if I stored encrypted credit card info in the browser's localstorage? When the user visits the site again, the credit card field is prepopulated by Javascript. The form itself points directly to a payment processor, so credit card info is never transmitted to my server.
Of course, my site and the payment processor's site are accessed via https.
Is this PCI compliant? Is this a bad way to do things?
I am not certain that falls under the pci-dss regulations. Storing customer data in potentially hackable files is the big concern.
Since the card # would essentially be stored on the client's machine, then (with my interpretation of pci-dss) you have no way to restrict or monitor access to that data even though its encrypted. Sounds to me to be non-compliant.
Not sure about PCI compliance, but you can also store credit card info in a HTTPS-only cookie.
We have several images and PDF documents that are available via our website. These images and documents are stored in source control and are copied content on deployment. We are considering creating a separate image server to put our stock images and PDF docs on - thus significantly decreasing the bulk of our deployment package.
Does anyone have experience with this approach?
I am wondering about any "gotchas" - like XSS issues and/or browser issues delivering content from the alternate sub-domain?
Pro:
Many browsers will only allocate two sockets to downloading assets from a single host. So if index.html is downloaded from www.domain.com and it references 6 image files, 3 javascript files, and 3 CSS files (all on www.domain.com), the browser will download them 2 at a time, with the other blocking until a socket is free.
If you pull the 6 image files off onto a separate host, say images.domain.com, you get an extra two sockets dedicated to download your images. This parallelizes the asset download process so, in theory, your page could render twice as fast.
Con:
If you're using SSL, you would need to either get an additional single-host SSL certificate for images.domain.com or a wildcard SSL certificate for *.domain.com (matches any subdomain). Failure to do so will generate a warning in the browser saying the page contains mixed secure and insecure content.
You will also, with a different domain, not send the cookies data with every request. This can increase performance.
Another thing not yet mentioned is that you can use different web servers to serve different sorts of content. For example, your static content could be served via lighttpd or nginx while still serving your dynamic content off Apache.
Pros:
-load balancing
-isolating a different functionality
Cons:
-more work (when you create a page on the main site you would have to maintain the resources on the separate server)
Things like XSS is a problem of code not sanitizing input (or output for that matter). The only issue that could arise is if you have sub-domain specific cookies that are used for authentication.. but that's really a trivial fix.
If you're serving HTTPS and you serve an image from an HTTP domain then you'll get browser security alert warnings pop up when you use it.
So if you do HTTPS, you'll need to buy HTTPS for your image domain awell if you don't want to annoy the hell out of your users :)
There are other ways around this, but it's not particularly in the scope of this answer - it was just a warning!