Security Vulnerabilities With Package

[harryWonder]

Internally, we discovered that this package calls this URL (https://api.paystack.co/checkout/request_inline), and that's fine. However certain details like the public_key are exposed when you inspect the browser Network tab, and even the reference for that transaction is exposed.

I have attached a sample request body that this package sends to the URL I mentioned earlier.

{
    "id": "paystackvlYSU",
    "key": "pk_live_xxxx_xxx76xxx_xxxxf",
    "ref": "ed343dcbc48fa4712f500dbe1fd9fd52d1e2214da230c37d135_xxxx_xxx",
    "email": "[email protected]",
    "amount": 50000,
    "currency": "NGN",
    "firstname": "Stephen",
    "lastname": "Ilori",
    "split": {},
    "bearer": "account",
    "metadata": "{\"firstName\":\"Stephen\",\"lastName\":\"Ilori\",\"emailAddress\":\"[email protected]\",\"customer_timezone\":\"Africa/Lagos\",\"custom_fields\":[{\"display_name\":\"firstName\",\"variable_name\":\"firstName\",\"value\":\"Stephen\"},{\"display_name\":\"lastName\",\"variable_name\":\"lastName\",\"value\":\"Ilori\"},{\"display_name\":\"emailAddress\",\"variable_name\":\"emailAddress\",\"value\":\"[email protected]\"}],\"referrer\":\"replaced_with_actual_url\"}",
    "mode": "popup",
    "hasTLSFallback": true,
    "device": "30140c9bf009f77cc5c305e84c7e5ace"
}

I believe that this request body should be encrypted at the point a call is made to your URL from this package. Even though you need to put a webhook in place or call a re-verify endpoint at the end of the day, I think we should make the frontend a little more secure by ensuring that this request is encrypted with the public key before it's sent out, else the public key is just serving as an Identifier for this request.

[1finedev]

It think it is called a PUBLIC KEY for a reason, that means it is safe to include it in the frontend JS bundles and it's also safe for it to show up in network requests

Also if you are on TLS or HTTPS nobody can read headers in AJAX requests apart from you who is inspecting your browser

[harryWonder]

Exactly my point. That means it's not safe. Anyone could be sniffing the request-response being exchanged, Someone could be using a tool like Fiddler for instance. I think it only makes sense to encrypt the request body that is being sent at that point, I get it that things like CARD details etc.

If you're already encrypting Payload sent at this level (https://standard.paystack.co/charge/), It shouldn't cost much to encrypt requests made to this URL(https://api.paystack.co/checkout/request_inline). What would an extra caution cause?

[1finedev]

I am not the maintainer of this package but I don't know how else to explain to you that exposing public keys are safe

Also that all api request and response are encrypted by default when using HTTPS.

How do you propose it's decrypted on paystack end if the package maintainer encrypts your payload ?

He would have to go and force paystack decrypt your requests!

[harryWonder]

I see what you mean, this invariably means that if you encrypt this, paystack still has to do a decryption on their end, and that’s not within your control. Warm Regards, Ilori Stephen A

…

On Wed, 15 May 2024 at 6:33 PM, Bayode Emmanuel ***@***.***> wrote: I am not the maintainer of this package but I don't know how else to explain to you that exposing public keys are safe Also that nobody api request and response are encrypted by default when using HTTPS. How do you propose it's decrypted on paystack end if the package maintainer encrypts your payload ? He should go and force paystack decrypt your requests?? — Reply to this email directly, view it on GitHub <#102 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJBHC7FDYHMXJNITRQS6RXLZCOL5NAVCNFSM6AAAAABHYSYD62VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJTGA4TAOBRGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[lebu7]

Paystack has a publickey and a secret key both for testing and production i think the publickey is ok to be exposed