fix: add sanitisation function for products #6880
Conversation
KenLSM
force-pushed
the
fix/payment-products-from-db
branch
from
9bf0320
to
bccc3c2
Compare
src/app/modules/submission/encrypt-submission/encrypt-submission.utils.ts
Outdated
Show resolved
Hide resolved
KenLSM
force-pushed
the
fix/payment-products-from-db
branch
from
88af378
to
e1c9b4f
Compare
src/app/modules/submission/encrypt-submission/encrypt-submission.utils.ts
Outdated
Show resolved
Hide resolved
| /** | ||
| * Sanitizes the payment fields from the form and the incoming submission | ||
| * The payment products from incoming submission can be freely altered by the respondent | ||
| * which could result in undesirable data seeded into our database | ||
| * @param form | ||
| * @param dirtyPaymentProducts | ||
| */ | ||
| export const sanitisePaymentProducts = ( |
There was a problem hiding this comment.
supernit: sanitize or sanitise? :)
| if (!dirtyProduct) return null | ||
|
|
||
| return { | ||
| ..._.pick(dirtyProduct, ['selected', 'quantity']), // only selected and quantity are allowed to be passed through |
There was a problem hiding this comment.
any particular reason to use lodash pick here as opposed to just { ...dirtyProduct, data: cleanProductData } or for even more safety, { selected: dirtyProduct.selected, quantity: dirtyProduct.quantity, data: cleanProductData } so that we can take advantage of the type system for typechecking? Since with pick, the keys are not typechecked.
There was a problem hiding this comment.
any particular reason to use lodash pick here as opposed to just { ...dirtyProduct, data: cleanProductData }
My intention was to operate as an explicit whitelist of properties that we will read from dirtyProduct, as opposed to accepting all the fields that are passed in. I felt that these properties are critical thus, it would be better to have them explicitly inherited rather than implicitly accepted.
Since with pick, the keys are not typechecked.
Lodash's pick does have typechecking, the selected property U must exist as a key in object T.
pick<T extends object, U extends keyof T>(object: T, ...props: Array<Many<U>>): Pick<T, U>;
Problem
Users can maliciously submit a product from FE to manipulate the product through scripts. This causes the product item evaluated on our BE to be incorrectly referencing the data from FE, instead of from the form payment products.
Solution
Don't trust FE.
Treat the product data from FE as dirty. Extract only the relevant details (quantity + selected) and replace the product data from the one in BE.
Breaking Changes
Tests
Regression
Payment by Product form submission should still work**
Variable Payment form submission should still work