I'm building a new web application that serves a form requesting the user's card information. Submitting this form will post the form data to a different, fully PCI-DSS compliant application.
Does the application that serves the form to users need to be PCI-DSS compliant also, even if I don't read card information in that application?
As far as my brief googling session has shown, it seems that PCI-DSS compliance is required in any application that "handles" card information. I'm not entirely sure where "handling" that information begins and ends.
PCI/DSS was updated in 2014 (with requirements that became mandatory in Jan 2015) to deal with services mechanisms like that used by stripe in the form of a more stringent self assessment questionnaire (SAQ A-EP V3) which is described as:
New SAQ to address requirements applicable to e-commerce merchants
with a websites that do not themselves receive cardholder data but
which do affect the security of the payment transaction and/or the
integrity of the page that accepts the consumer’s cardholder data.
Content aligns with PCI DSS v3.0 requirements and testing procedures.
This makes it clear that compliancy is required.
Your use case sounds similar to Stripe's, and they say you'd need to use SSL on your page but otherwise can self-attest to compliance.
https://support.stripe.com/questions/do-i-need-to-be-pci-compliant-what-do-i-have-to-do
You may want to consult an auditor and get a formal opinion from them, though.
Related
HTTP cookies violate the REST architectural style because they are independent of application state and they have no semantics, according to Roy Fielding’s doctoral dissertation Architectural Styles and the Design of Network-Based Software Architectures, § 6.3.4.2 ‘Cookies’:
An example of where an inappropriate extension has been made to the protocol to support features that contradict the desired properties of the generic interface is the introduction of site-wide state information in the form of HTTP cookies. Cookie interaction fails to match REST's model of application state, often resulting in confusion for the typical browser application.
Cookies also violate REST because they allow data to be passed without sufficiently identifying its semantics, thus becoming a concern for both security and privacy. The combination of cookies with the Referer [sic] header field makes it possible to track a user as they browse between sites.
So he suggests the following alternative:
As a result, cookie-based applications on the Web will never be reliable. The same functionality should have been accomplished via anonymous authentication and true client-side state. A state mechanism that involves preferences can be more efficiently implemented using judicious use of context-setting URI rather than cookies, where judicious means one URI per state rather than an unbounded number of URI due to the embedding of a user-id. Likewise, the use of cookies to identify a user-specific "shopping basket" within a server-side database could be more efficiently implemented by defining the semantics of shopping items within the hypermedia data formats, allowing the user agent to select and store those items within their own client-side shopping basket, complete with a URI to be used for check-out when the client is ready to purchase.
My understanding of his user preference example is the following. Let’s say that a website allows its users to choose between a light theme (the default) and a dark theme in a preference page at URI /preferences (like Stack Overflow). When a user chooses the dark theme, he should be redirected to the URI /preferences?theme=dark whose HTML representation will be the same as the HTML representation of the URI /preferences, except that it will be now in dark mode and the query ?theme=dark will be appended to all the embedded hyperlinks. That way, if the user selects for instance the embedded hyperlink to the home page at URI /home?theme=dark (not /home), then the HTML representation of the home page will also be in dark mode and the query ?theme=dark will also be appended to all its embedded hyperlinks. To revert to the light theme, then the user selects the embedded hyperlink to the preference page at URI /preferences?theme=dark, chooses the light theme in the preference page and should be redirected to the URI /preferences whose HTML representation will be the same as the HTML representation of the URI /preferences?theme=dark, except that it will be now in light mode and the query ?theme=dark will be removed from all the embedded hyperlinks. Is it what Roy Fielding meant?
Likewise for his shopping cart example, when the user adds a product i to cart, he should be redirected to a URI with a query ?product-{i}={product-i}&quantity-{i}={quantity-i} whose HTML representation will have that query appended to all its embedded hyperlinks. That way, when the user selects the check out hyperlink /checkout?product-1={product-1}&quantity-1={quantity-1}&…&product-n={product-n}&quantity-n={quantity-n}, the content of the shopping cart is sent to the website. Is it what Roy Fielding meant?
I believe you are correctly interpretting Fielding's thesis in the first case, but not the second.
Your interpretation of "preferences" seems exactly correct: it's perfectly reasonable to have multiple resources whose representations include the same information, but different presentation, like having a dark theme and a light theme as parallel resource structures.
But I believe that you misinterpret Fielding's proposal of "client-side shopping basket". He's not proposing introducing server side resources to be edited (after all, this capability already exists in the web we have today); but rather the introduction of a general purpose language for storing interesting pieces of client state on the client.
In other words, Fielding is talking about introducing within the HTML standard some controls (similar to the controls of a web form) that would allow the human to save some information would would later be loaded into a form when actually placing an order.
Imagine, if you will, a special kind of form that, when submitted, edits a resource that is local to the web browser itself. So you could pick items out of a catalog, and in doing so your local shopping cart resource would be modified. When you were ready to check out, the contents of your shopping cart would be available to sent to the server.
In the same way that forms are general purpose, and can be used for many different domains, so to we would want this shopping cart plumbing to be general purpose, so that it could be used for any sort of "copy this information to be used later" mechanism.
The trick (that didn't happen) is defining a standard and then getting everybody (browsers makers) to implement those standards in similar enough ways that everything just works.
As I've also stated in the comments above, I haven't read Fielding's dissertation, but I've been thinking some more about this question and decided to type down my thoughts nonetheless.
I don't think one needs to read the dissertation to understand REST design. I'm not saying this to belittle Fielding's work, which is clearly hugely influential. On the other hand, the dissertation is from 2000, and can't be based on much practical experience. I was a junior developer in 2000, and believe me, REST wasn't a thing. If you did web services at all, SOAP was where it was at.
I've learned REST mainly from Subbu Allamaraju's RESTful Web Services Cookbook and Ian Robinson, Jim Webber, and Savas Parastatidis' REST in Practice. It seems to me that these books are based on more practical experience with developing production services than Fielding could possibly have had when he wrote the dissertation.
All that said, I think I can parse the Fielding quote about a shopping basket:
defining the semantics of shopping items within the hypermedia data formats, allowing the user agent to select and store those items within their own client-side shopping basket, complete with a URI to be used for check-out when the client is ready to purchase
Notice that it talks about a client-side shopping basket. This means that it's the client's responsibility to keep track of state.
The way that I interpret this is that each shopping item is a separate resource, which is hardly controversial. In REST, resources are identified by address, so a shopping basket would simply be a collection of URLs:
/products/12345
/products/56789
/products/90125
A client would have to maintain a list of resource addresses like the above list. Once it's ready to check out, it'd POST the list to the URI given to it for that purpose:
POST /check-out HTTP/1.1
Content-Type: text/plain
/products/12345
/products/56789
/products/90125
Here, I've just used a newline-separated plain-text list, but one could also encode the data in XML or JSON (the latter of which also wasn't really a thing in 2000).
I don't think that I'd design a RESTful shopping basket quite like that, but that's how I interpret the above quote.
As a newbie to Yodlee platform, I understand the basic concepts of Aggregation API .
Is there a way to plug in as a bank to supply direct data link instead of screen scraping to supply yodlee plaf and data model to be supplied to devs?
Yes a bank can feed obfuscated data, this is done by placing a middleware server between the core banking and the channel delivery switch.
Companies like Yodlee and Mint, et. al., rely on such a mechanism to provide access to their information partners.
Having said this, I'd be very surprised if any bank would provide you with direct access. Its a pretty cumbersome process even for the most reputed and well-intentioned of companies, individually, I doubt you will get direct access.
Totally new to server-side programming and I am wondering about best practices regarding gathering information from a service like Stripe Payments, for example.
For some context -- a stripe customer can have multiple payment cards, one of which is considered the default payment card.
Now lets say a client hits my server and wants the default payment card for customer XX. My question is: should I be maintaining my own stripe database info, or should I just forward that request to stripe directly?
On the one hand, storing that information locally means I don't have to rely on a second network request to gather that information -- I can just send back directly what is in my database.
On the other hand, storing that information locally means I've got more code to maintain, and now I've got to worry about keeping it reflective of the true data over at stripe. That problem is solvable, but does the cost of doing so outweigh the negatives of extra API calls??
Any thoughts? I'd love to hear some opinions as this is very new to me :)
thanks!
Generally it's a good idea to keep a local copy of the data you get from Stripe API in your own database. Otherwise you will have to make too many calls to Stripe API which will slow down your server requests.
In order to keep your local database synchronized with Stripe you should use the webhooks in Stripe.
https://stripe.com/docs/webhooks
We need to accept credit cards (from anywhere in the world) directly on our website. We'd like to use PayPal, but NOT require a PayPal account. The user should be able to simply type in the credit card, date and cvv directly on our site and go. I'm having a hard time figuring out what PayPal API I need to use for this, to integrate with our Java-based server. Turns out PayPal has an overwhelming number of APIs and documentation.
It looks like this link is what I'm looking for... sort of. But can I post this directly from JavaScript? It includes account name and password, which would be in the clear for anyone to see, so I'm thinking this must be server-side code. So the idea is to use a REST API to do this? So the client must pass the credit card information to my server, which then calls PayPal's server?
I'm a little lost, when looking at all the APIs at the Rest API page. Which ones exactly do I need to use?
There is also this link but I'm not familiar with "curl" -- looking for Java. Maybe the distinction is minor and easy to convert from one to the other?
Vern, if you look at the top of this page, you'll see Java (click Java) as one of the languages supported by the PayPal REST Payment API:
https://developer.paypal.com/webapps/developer/docs/api/
You will see related sample requests that use the Java SDK:
https://github.com/paypal/rest-api-sdk-java
in SAML 2.0 you can use the AttributeStatement element to provide any kind of application specific information.
What I was wondering, is it really good design to pass business related information within a SAML assertion? Shouldn't this data be provided in a e.g. separate web services call?
I just want to ask for best practice in this case or any real world experiences.
Regards,
Andreas
It depends a lot on just what information you're conveying. For instance, on the application I work on, we use attributes to indicate what web site features should be shown to the user being logged on. That's clearly an appropriate use. Now, we also allow use of attributes to create a user profile, even though we have a web service that does the same thing (and in fact, the implementation calls the web service behind the scenes). It's not an ideal context for that sort of thing; there's no endpoint to convey the web service response to, or any errors resulting from the attempt. But we get a fair amount of resistance from customers, who don't want to have to call a separate web service before they can make an SSO call. So we've had to compromise. What we've done is require that if a customer wants to use this particular functionality, that they provide an endpoint (either email address or web page) to receive errors from the web service call. And if they're concerned about security of the information being conveyed, they can use standard XML encryption.