Opencart used to have a CSRF vulnerability. This has lately been fixed apparently. Even so if there are still security issues does it even matter if Paypal is the only payment gateway method used (i.e does Paypal's own security override opencart's or any other e-commerce shopping cart for that matter?).
CSRF was fixed over a year ago in OpenCart (version 1.4.8 or 1.4.8b I think it was) - it's only on the admin side that this was ever done, so it has no effect on your payment gateway etc
You should use an SSL certificate for any site you intend to take people's personal information, regardless of how they make payments. That said, paypal (standard) will use all of paypals security, and as such you don't need to worry about that side of things, as any liability will lay with them should any payment details be lost/stolen during that process.
That said, I've never had an issue with any of my sites or client sites where any user information has been stolen as a result of bad paypal security, not have I actually heard anyone has to be honest, so you're in good hands if you use them
Related
I am developing an eshop website based on Nuxt.js (Vue) for the frontend and Laravel for the backend.
I am at the stage where the payment is being done and thinking what my options are.
My payments provider offers two options: Redirect and Native.
The first option basically redirects the user from my spa to the payments provider page to fill in their card details and perform the transaction. Afterwards it redirects back to a predefined page. This option although it is really common (pretty much every company uses it) it also has the disadvantage that the spa loses its state.
The second option is to have a form inside my spa that sends the information to my api which finally performs the request to the payment provider and completes the transaction.
I believe the second option is the best in terms of ux but I am mostly writing this question to ask for your thoughts on this mostly related to law terms and security in general.
Note that I won't store any card details in the second case but even then, can this process be a bad thing for my company?
Quick disclosure: I'm new to stackoverflow and don't have the points to add comments.
Are you currently integrated with Braintree? The Drop-in UI is an excellent way to complete a transaction in a Single Page Application without worrying about page re-directs.
Full disclosure: I work at Braintree. If you have any further questions, feel free to contact Braintree Support.
I realise this is very vague I'm just trying to work out if I can do something. How would I go about building something similar to this in wordpress? is it possible?
http://www.thesisonline.co.uk/
What it needs to do
1. User uploads a file
2. User fills in a form that calculates a cost
3. Cost is passed securely, to a secure form that the user can enter their credit card details and pay.
I imagine for the last step I'll have to use something to make it secure and all legal, sage pay etc. not sure which is the best option.
Well i am not an expert of WordPress but what you have mentioned is quite possible in WordPress with some coding skills and using any of existing e-commerce plugin available in WordPress.
How the cost will be calculated is entirely dependents upon you and how to set your business rules, once you have your business rules to calculate the cost you can proceed for payment.
This is the main secure and sensitive part of any e-commerce application and you have to integrate your application with Payment Gateways so that things can be handled by the gateway itself for you (like security and other things)
i just saw this plugin of WordPress WordPress E commerce plugin and it provides integration with payment gateway which means your most of the work has already been done by the plugin itself
but if you are working towards a serious e-commerce application always suggest you to choose any e-commerce platform rather than an extension of a platform which is developed with some other objectives.
I'm building a website for a sports center. Registrations are handled through a third-party software program. There are options to register directly through the third party's site or to integrate the registration form into my site with iframes.
Since I'd rather not send people to another site, I went with the iframes option. My question is, can I be sure that people will be getting the same level of security in the iframe as they would on the completely-secure third-party page?
Thank you.
This design does make you more prone to SSLStrip. I recommended watching the video of Moxie Marlenspike's Talk. Although in practice such an attack isn't common.
This iframe would not be a violation of OWASP A9: Insufficient Transport Layer Protection. However if you are planning on letting people login to the HTTP site, or if you are transmitting a session id over HTTP then this would be clear violation of OWASP A9.
In short, https is absolutely necessary to protect your users.
I've been doing a fair bit of work with OAuth recently, and I have to say that I really like it. I like the concept, and I like how it provides a low barrier-of-entry for your users to connect up the external data to your site (or for you to provide the data apis for consumption externally). Personally, I've always balked at sites that ask me to provide my login for another website to them directly. And OAuth "valet key for the web" approach solves this nicely.
The biggest problem I (and many others) see with it though, is the standard OAuth work-flow encourages the same type of behaviors that phishing attacks use to their advantage. If you train your user that it is normal behavior to be redirected to a site to provide login credentials, then it is easy for a phishing site to exploit that normal behavior but instead redirect to their clone site where they capture your username and password.
What, if anything, have you done (or seen done) to alleviate this problem?
Do you tell the users to go and login to the providing site manually, without automatic links or redirection? (but then this increases the barrier of entry)
Do you attempt to educate your users, and if so, when and how? Any lengthy explanation of security that the user has to read also increases the barrier of entry.
What else?
I believe that OAUth and phishing they are inexorably linked, at least in OAuth's current form. There have been systems in place to prevent Phishing, most notability HTTPs (pause for laughter...), but obviously it doesn't work.
Phishing is a very successful attack against systems that require username/password combos. As long as people use usernames and password for authentication phishing will always be a problem. A better system is to use asymmetric cryptography for authentication. All modern browsers have built in support for smart cards. You can't phish a card sitting in someones wallet and hacking the user's desktop won't leak the private key. The asymmetric keypair doesn't have to be on a smartcard, but I think that it builds a stronger system than if it where purely implemented in software.
You have an account with the site you are being redirected to, shouldn't they be implementing anti-phishing measures such as a signature phrase and image? This also leverages any existing training the users have received from e.g. banks who commonly use these measures.
In general, the sign-in page should present user-friendly shared secrets to the user to confirm the identity of the site they are logging into.
As Jingle notes, a ssl certificate could be used for authentication, but in this case couldn't the user load a certificate directly from the site into their web browser as part of the OAuth setup process? If a trust relationship has already been established with the site, I'm not sure further resort to a CA is necessary.
There are some techniques that can be used to avoid or diminish phishing attacks. I made a list of cheap options:
Mutual identification resources. E.x. icon associated with a specific user shown only after user input his username.
Use of usernames not deterministic and avoid emails as usernames.
Include option to user see his login history.
QRCode that allows authentication in device pre-registered like smartphones. Like whatsapp web.
Show authentication numbers in login pages that the user can validate in the official company site.
All options listed above highly depends on user education about information security and privacy. Wizards that appears only on the first authentication can helps achieve this goal.
To extend the valet analogy: how do you know you can trust the valet, and that he/she is not just someone trying it on? You don't really: you just make that (perhaps unconscious) judgement based on context: you know the hotel, you've bene there before, you might even recognise the person to whom you're giving your key.
In the same way, when you sign in using OAuth (or OpenID), you are redirecting the user to a site/URL which should be familiar to them, seeing as they are providing their credentials from that site which is known to them.
This isn't just an OAuth problem, it's OpenID's problem as well. Worse of course with OpenID you're giving a web site your provider, it's easy to automatically scrape that site if you don't have a bogus one already and generate one which you then direct your user too.
It's lucky that nothing serious uses OpenID to authenticate - blog posts, flickr comments just aren't a juicy target.
Now OpenID are going somewhere to mitigation as they start to develop their Information Card support, where a fixed UI in the shape of client side software will provide an identity "wallet" which is secure, but MS appear to have dropped the ball themselves on Information Cards, even though it's their (open) spec.
It's not going away anytime soon.
What about to certify the oAuth provider just like the ssl certification? Only certified oAuth provider is trustworthy. But the problem is, as with ssl certification, the CA matters.
Currently, I'm in the process of hiring a web developer who will be working on a site that processes credit cards. While he won't have the credentials to log into the payment gateway's UI he will have access to the API login and transaction key since it's embedded in the application's code.
I'd like to be aware of all the "what if" scenarios pertaining to the type of damage one could do with that information. Obviously, he can process credit cards but the money goes into the site owner's bank account so I'm not sure how much damage that could cause. Can anyone think of any other possible scenarios?
UPDATE: The payment gateway being used is Authorize.net.
Do they really need access to your production sites?
Don't store the key in your code, store it in your production database, or on a file on the production server.
Some good answers here, I'll just add that you'd probably have some trouble with PCI.
PCI-DSS specifically dictates separation of duties, isolation of production environments from dev/test, protection of encryption keys from anyone who does not require it, and more.
As #Matthew Watson said, rethink this, and dont grant production access to developers.
As an aside, if he can access the API directly, how do you ensure that "the money goes into the site owner's bank account"? Not to mention access to all that credit card data...
If the developer gets access to the raw credit card numbers that can become a bigger problem as your site can be associated with fraudulent activity, assuming the developer is a bad apple. (They could redirect account numbers, CCV, expiration date to another site, though this should be spottable through network tools and a comprehensive code review.)
Does the API perform the "$1.00" charge (or "$X.XX") to verify that a credit card can be charged a certain amount (and thus returning the result to the caller, such as "yes" or "no")? If so, it could be used to automate the validation of credit card account numbers traded on the Internet and abuse of such a system could lead back to you.
With any gateway I have worked with, the payment processor ties the API key to the specific IP or IP range of the site of the merchant. With that said, unless the malicious(?) code in question is executed on the same server as the merchant - there shouldn't be any security concerns in that regard.
If this is not the case for your merchant site - contact them and ask if this is feasible.
Does the payment gateway allow for reversal of charges? If so there is the possibility of a number of scams being run.
Does the site process refunds? Will it ever in the future?
If we're talking about nefarious uses, then the site owner might be investigated if lots of unauthorized purchases are made. How would that affect you if the owner is investigated?
From your description it seems that this developer will have access to the customer cards detail in which case the customers privacy may be compromised. You might consider wording the contract appropriately to make sure that this angle is covered.
However the main point is that if you're working on a sensitive project/information it's better for you to find people you could trust. Hiring a software house to do the job may save you some sleep later on.
First and foremost, it is best that you never store this type of information in plain text. Usually people take this as second-hand knowledge for credit card numbers (Sadly, only because of legal reasons), but any sort of private data that you don't want others with database/source-code access viewing should be encrypted. You should store the account information somewhere in a well encrypted format, and you should provide a test account for your developers to use on their development workstations. This way, only people with server access are able to see even the encrypted information.
This way, you can have a database on the developer's workstation with the test account's API information stored (hopefully encrypted) in it's local database, but when the code is mirrored onto the production server it will still use the live, real gateway information stored on the production server's database without extra code/configuration.
With this said, I don't think that a programmer with API authentication details can do too much. Either way, it's not worth the risk - in my opinion.
Hope this help.
PS: If something bad does end up happening, you can always generate a new key in the web interface on authorize.net after you've taken the precautions to make sure it wont happen again.
In the specific case of Authorize.Net they would not be able to do credits towards their own credit cards since Authorize.Net only allows this to be done on transactions performed through them within the last six months. The only exception being allowed if you are granted an exception for unlinked refunds. If you have signed the proper paperwork for this and someone has your API login and transaction key then can then process credits towards their own credit cards. The only way for you to catch this would be to monitor your statements carefully.
To help mitigate this you should change your transaction key immediately upon completion of the work they perform for you. That would render the key they have useless after 24 hours.