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.
Related
paymentRequest API documentation tells that a merchant can provide details to browser of what all kinds of card it supports. My question is how does browser knows the card types stored by the user and filter it.
Let me talk about Chrome in particular. Chrome's credit card autofill storage sources from 2 places:
locally stored cards
cards stored at payments.google.com
For 2, Google server knows type of cards from their numbers. So they can be filtered. For 1, Chrome does not have a way to distinguish them so all available cards will be exposed without being filtered.
It may depend on implementations, but payment gateways should be able to handle card numbers gracefully without knowing their types. I've confirmed Stripe does at least.
If you do need to check the type of cards, there are online services like https://binlist.net/ which tells you meta information about a card from its first few digits.
I'm planning to use the HTML LocalStorage capability of browsers (FF especially) to store data of our intranet application.
I've read about it, how to use, the per domain isolation of data, how the user may increase it's quota, and so on.
But the question is if this quota is shared? Or does each domain has 5Mb to use?
(*) And, if I need to use, say 25Mb, and I ask my clients to increase their browser quota, does that means that all other domains may have this 25MB at disposal?
Or, if another domain uses all of the quota, is there no space left to my app?
UPDATE:
There's a (sub)question related to change browser config to allow more space (*). Althrough the below seems to be a recomendation, does anyone knows if is that implemented on FF?
11.3 Disk space
User agents should limit the total amount of space allowed for storage
areas, because hostile authors could otherwise use this feature to
exhaust the user's available disk space.
User agents should guard against sites storing data under their
origin's other affiliated sites, e.g. storing up to the limit in
a1.example.com, a2.example.com, a3.example.com, etc, circumventing the
main example.com storage limit.
User agents may prompt the user when quotas are reached, allowing the
user to grant a site more space. This enables sites to store many
user-created documents on the user's computer, for instance.
User agents should allow users to see how much space each domain is
using.
A mostly arbitrary limit of five megabytes per origin is suggested.
Implementation feedback is welcome and will be used to update this
suggestion in the future.
For predictability, quotas should be based on the uncompressed size of
data stored.
No, the quota is not shared across domains.
The reason for this is as you said - one domain might use up the browser's entire quota, and leave nothing for other sites.
To see how much storage is provided across different browsers, and to test your own, you can visit http://dev-test.nemikor.com/web-storage/support-test/
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).
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.
It is impossible to identify a user or request as unique since duping is trivial.
However, there are a handful of methods that, combined, can hamper cheating attempts and give a user quasi-unique status.
I know of the following:
IP Address - store the IP address of each visitor in a database of some sort
Can be faked
Multiple computers/users can have the same address
Users with dynamic IP addresses (some ISP issue them)
Cookie tracking - store a cookie per visitor. Visitors that don't have it are considered "unique"
Can be faked
Cookies can be blocked or cleared via browser
Are there more ways to track non-authorized (non-login, non-authentication) website visitors?
There are actually many ways you can detect a "unique" user. Many of these methods are used by our marketing friends. It get's even easier when you have plugins enabled such as Java, Flash etc.
Currently my favorite presentation of cookie based tracking is evercookie (http://samy.pl/evercookie/). It creates a "permanent" cookie via multiple storage mechanisms, the average user is not able to flush, specifically it uses:
Standard HTTP Cookies
Local Shared Objects (Flash Cookies)
Silverlight Isolated Storage
Storing cookies in RGB values of
auto-generated, force-cached PNGs
using HTML5 Canvas tag to read pixels
(cookies) back out
Storing cookies in Web History
Storing cookies in HTTP ETags
Storing cookies in Web cache
window.name caching
Internet Explorer userData storage
HTML5 Session Storage
HTML5 Local Storage
HTML5 Global Storage
HTML5 Database Storage via SQLite
I can't remember the URL, but there is also a site which tells you how "anonymous" you are based on everything it can gather from your web browser: What plugins you have loaded, what version, what language, screensize, ... Then you can leverage the plugins I was talking about earlier (Flash, Java, ...) to find out even more about the user. I'll edit this post when I find the page whcih showed you "how unique you are" or maybe somebody knows »» actually it looks as if every user is in a way unique!
--EDIT--
Found the page I was talking about: Panopticlick - "How Unique and trackable is your browser".
It collects stuff like User Agent, HTTP_ACCEPT headers, Browser Plugins, Time Zone, Screen Size and Depth, System Fonts (via Java?), Cookies...
My result: Your browser fingerprint appears to be unique among the 1,221,154 tested so far.
Panopticlick has a quite refined method for checking for unique users using fingerprinting. Apart from IP-adress and user-agent it used things like timezone, screen resolution, fonts installed on the system and plugins installed in the browser etc, so it comes up with a very distinct ID for each and every user without storing anything in their computers. False negatives (finding two different users with the exact same fingerprint) are very rare.
A problem with that approach is that it can yield some false positive, i.e. it considers the same user to be a new one if they've installed a new font for example. If this is ok or not depends on your application I suppose.
Yes, it's impossible to tell anonymous visitors apart with 100% certainty. The best that you can do is to gather the information that you have, and try to tell as many visitors apart as you can.
There is one more piece of infomration that you can use:
Browser string
It's not unique, but in combination with the other information it increases the resolution.
If you need to tell the visitors apart with 100% certainty, then you need to make them log in.
There is no sure-fire way to achieve this, in my view. Of your options, cookies are the most likely to yield a reasonably realistic number. NATing and proxy servers can mask the IP addresses of a large number of users, and dynamic IP address allocation will confuse the results for a lot of others
Have you considered using e.g Google Analytics or similar? They do unique visitor tracking as part of their service, and they probably have a lot more money to throw at finding heuristic solutions to this problem than you or I. Just a thought!