When is it recommended to validate the paypal IPN?
Option 1 - Validate during the handler ipn post, then save and enqueue ipn if valid.
Pros: An attacker can not fill your database by sending fake IPNs
Cons:
Requires a longer response time for ipn post since you need to
make a web request to validate, before being able to respond with a 200 OK in the ipn handler
An attacker can keep your web server busy trying to validate fake IPNs
Option 2 - Delay validation, save and enqueue ipn, respond with 200, then validate when processing the queue.
Pros: Quick response to paypal IPN
Cons: An attacker can fill your database by sending fake IPNs
Or do you do have something additional in place that avoids the problems of these two options?
Edit: I'm using the Paypal Adaptive Payments API, and am wondering what the recommended practice is while using that API.
PayPal now supports sending shared secrets instead of postback validation. I prefer this provided (a) your buttons use HTTPS when posting and (a) your notify_url uses HTTPS.
Postback validation has a number of problems, starting with the requirement that the same POST variables be used in the same order. This isn't implementable e.g. in servlets where you don't have that level of control. However in fact it doesn't appear to actually matter, which casts doubt on other security aspects of the procedure.
Related
Block or limit visitor's(just viewing a website, no user registration) multiple form submission in Laravel by getting client IP and saving it in database then use it to detect spamming visitors. is that possible?
I wouldn't recommend using a visitors IP to prevent future requests to your site via forms. IP's are very rarely static for the average user. If the user knows what they're doing, they'd just have to restart their internet connection and their ISP would give them a different IP address. Additionally, they could just proxy their requests utilising IP rotation to bypass your "security".
If you're trying to prevent bots from submitting forms. A good method is to implement a hidden input field with no value. If the form is submitted and the input field has been populated then you know it's a bot. It's not the most reliable method as the bot has to be a dumb bot.
The only truly "reliable" method I can think of is Client-Side > Server-Side validation such as Google ReCaptcha.
Ofcourse the alternate method is just accept that your form will get spammed and find a way to handle the spam after it's been submitted.
I am currently using the braintree server package (Node.js) and am working towards implementing subscriptions.
As an intermediate step, I'm managing a list of payment methods for each customer, which is found inside a customer object: customer.paymentMethods.
I want to be sure that passing this list directly to the client is an ok thing to do. Essentially, I'd like to list all of the current payment methods, and also create a way to add new ones / remove existing ones. When a payment method is selected, I can pass the payment_method_token to the server to perform a particular action with this payment method.
As I'm only passing payment tokens to the user when they have the proper session, it seems safe to be passing tokens around in this way, but I want to be positive that I'm doing this correctly.
Can somebody verify whether or not this approach is ok?
Seems to me that 1) this is a lot of unneeded work and 2) not really what you should be doing...
You should be passing the payment nonce around - the SDKs do all the other work for you - https://developers.braintreepayments.com/start/overview
Specifically, for the subscription flow, see https://developers.braintreepayments.com/guides/recurring-billing/create/node - you need the paymentMethodToken, which comes from the nonce (either from the client or one stored on your server) and a planID that is set up in the Control Panel. The paymentMethodToken is not passed around, it is created (and can/should be stored) server side.
I wanted to verify phone numbers before using them for communication with registred users. However, I am unclear If I'm doing it securely. i.e
Steps I'm taking:
Ask user for phone number
Send SMS verification code
User enters Code
Code verified using SMS Service(Sinch or/Twilio)
correct code triggers callback function(client side) that adds the number to backend Database
Incorrect code does nothing
My concern is step 5. Should I have the success callback function perform the number save on client side or should I trigger some backend(server-side) function that performs the save operation?
So with sinch it works like this, all the steps 1 to 6 is correct on the client.
side,
But step 5/6 is more like this
5 Client enters code and send it to Sinch Backend
- Return to client with Success or Fail (do ui logic)
- Make a callback to your server with status, take action if correct or incorrect.
So the code is never in your possession, injecting the add to database on client side not possible, since you can get Success to the client and then in the client reload you data from your backend that has been updated by the server to server method. Makes sense?
https://www.sinch.com/docs/verification/rest/#howtousetheverificationapis
Twilio developer evangelist here.
I'd definitely do the code verification on the server side and then if that is successful save the number to the database. Any verification and success callbacks on the client side could surely be bypassed by an attacker with knowledge of JavaScript.
Rather than using Twilio directly for this, might I suggest you check out Authy's phone verification API. Authy is part of Twilio, but is more specific to verification and two factor authentication workflows.
I'm not sure what your backend is written in, however there are tutorials for verifying a phone number with Authy on the Twilio site. We have examples in Node, Ruby, Python, .NET, PHP and Java.
I'm not sure if this helps at all. Let me know if you have any other questions.
edit:
tl;dr: you can't.
You have to create a payment method in order to verify it. Creating a sale does NOT invoke verification, even if verification is enabled globally.
original:
I'm reading about credit card verification, which apparently isn't done automatically during Braintree_Transaction::sale(), but I don't see any options to enable verification on calling sale().
Do I really have to implement (at least) two separate API transactions just to verify a credit card?
Ideally I would like to use a single call to ::sale() to perform validation, authorization, and capture.
I have already enabled verification through my control panel, and I'm using test credit card number 4000111111111115 which, is supposed to be declined, but i'm getting successful transactions with it.
Do I have to create a payment method separately in order to perform validation, even if I have global validation enabled?
Full disclosure: I work at Braintree. If you have any further questions, feel free to contact support.
To test card verification results, please adjust the amount of your transaction. Because these cards are not linked to real accounts, Braintree cannot make the small authorization charges that are made in production, and instead the API must rely on the amount of the test transaction to dictate the expected response.
In a Production environment, Card verification is triggered by the creation of payment methods, not by transactions. To enable verification, either enable it across all payment methods, or add the verifyCard option to your PaymentMethod::Create call. The response to PaymentMethod::Create in either of these cases will contain a creditCardVerification object if the verification fails for any reason, allowing you to stop the transaction before sale is called.
I'm setting up a website that uses paypal to process payments.
The easiest way to implement the checkout form would be to create an HTML form that submits directly to paypal, sending the order details and redirecting the user to paypal in order to finalize the transaction.
However, there is a security vulnerability with this process. The client could edit the information submitted to paypal, such as changing the price of the checkout to $0.00.
What is an accepted way to handle this type of situation? Is it to submit the form back to my server, then do some processing in PHP, then submit verified data to paypal and redirect the user to paypal? Is this possible?
Thanks!
There are two main ways to handle this issue.
The first is somewhat like what you outline: You send the filled in form to PayPal, and provide a callback-url. When PayPal has processed the payment, they will call your provided url, and you can check whether or not the information given in that call is the same as what you provided. For this to work, you need to store the information in the meantime, like in a database. You will then only give access to the product after the validation has happened.
You can also encrypt the information you send to PayPal, making it practically impossible to alter information in your form.
See https://www.x.com/developers/paypal for details.