Wk-notes-02-26-React-form-validation-Boolean-algebra-Rule-for-this-App-security-npm-devtool-tricks

React form validation

Challenge

• Reuse validation rules, how much flexibility, to compose rules, declarative way and

• Dependencies, from redux, window, (Parent) Components, form state, react-context

• When to run validation, onChange, onBlur, onSubmit, imperative manual trigger will cause nightmare

• Async validation, needed to be cancellable

• Dirty/touch check is validations is declarative and run on every fields (which is good)

Common practice

Form-level Validation

Complete access to all form state and props whenever the function runs, so you can validate dependent fields at the same time.

validationContext can be passed and handled from the same level (top-level)

Formik:

<Formik validate={fn}> and withFormik({ validate: fn }), fn as (formInfo) => errors

<Formik validationSchema={yupSchema}> and withFormik({ validationSchema: yupSchema })

React-Hook-Form:

const { register, handleSubmit, errors } = useForm({
    validationResolver: resolver,
    /*
    resolver as (data, context) => errors;
    */
    validationContext: { test: "test" }
  });

etc.

Yup is awesome

Field-level validation

Formik: <Field component={Input} name="name" validation={validationFn}>

Ref: https://jaredpalmer.com/formik/docs/guides/validation

React-Hook-Form:

<Controller as={TextField} name="TextField" control={control} defaultValue="" rule={validationObject}/>

or

<input ref={register(ValidationObject)} name="Name"/>

etc.

Flight Search validation

Too much binding, for each validation rule: validation id binds to i18n, rule, it supposed to be easy for compose and plug.

For rules based logic, consider boolean algebra, and using correct AND, OR, XOR rules:

validationsToTrigger for onChange event, validationsToClear for Priority overwrite. validationsToClear can be used for each validation rules, or fields

Interpretation on this

The binding this in javascript can be interpretated as, if there is a this pointer in function:

• If you want to passing function around, or ensure using this in current context, MUST use arrow function () => {};

• If you want to use this in some other context, late binding, use function(){}

To make things even easier, rules (almost a silver bullet) can be:

ONLY use function(){}, if you want to use a late bound this.

Application Security for frontend

There is no 100% secure, it's a resource competition, if the resource to break the system(the resource you put in) is greater than the resource attacker has, it's unbreakable.

OWASP Top 10

Pass the top 10 could be a good sign that your app is secure in a credible level.

• Injection: client env ALWAYS hostile; NO SQL/commands direct concat; Sanitize; Limit SELECT/amount of data returned

• Broken auth: Phishing, Credential stuffing(same pwd), Weak pwd encryption(unsalted), MFA, Proper session and rotation(session disable strategy)

• Sensitive Data Exposure: Man in the middle(MITM), HTTP Strict Transport Security (HSTS), Weak key encryption, Certification verification

• XML vulnerability: Break XML while parsing/XML execute commands, ref
• Broken Access Control: CORS, Principle of least privilege

• Security Misconfiguration: Exposure of data or access control, Tech debt & deprecated controls,

• XXS: Stored XXS, DOM XXS

• Incorrect Deserialization

• Use Component with Known Vunaribility

• Insufficient Logging/Monitoring

Security Framework

A standard to do things.

Auditing Tools

How to break things by your own npm pkg

https://medium.com/hackernoon/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5

• npm can be a distribution method. Using different accouts to send PRs to open source JSlibs with your dependency. It's a numbers game, some will get merged, and that's enough.

• Detect devtool open/close status and stop sending data when open.
• Stop sending data in localhost or staging server, to bypass pen-test

• Publish different code to npm from github code, .gitignore lib folder, and manually uglify malicious lib code and publish.

• Easy to do obscured string magic to bypass keywords like fetch, request, etc.

• Use prefetch to bypass some more

Key take away:

My goal (as it turns out) is simply to point out that any site that includes third party code is alarmingly vulnerable, in a completely undetectable way.

Thoughts

To be honest if you enable dynamic javascript on your website that is externally hosted (most tag managers), you have made a decision to accept that risk but hopefully the business is aware of the trade offs just as much as the benefits. You can remove it from one page but as long as one page on your website has dynamic javascript the risk has only been slightly mitagated. Even removing a tag manager from a booking engine isn't foolproof if the website that takes you to the engine still has dynamic javascript then you can just redirect someone to some other malicious server that mimics the look and feel. Csp, the solutions this guy proposes in part 2, none of them are full proof. GTM is only acceptable because of the 2FA and I'm sure if you read their T&C it will say that the people you provide access to is your responsibility. Without self hosting a tag manager it's quite difficult to secure. As for ab testing we should pick a tool that can't execute javascript but provides an api for the variables that are enabled.

The article focuses on only one type of XSS. If you don't mitagate them all, all you've done is just add a speed bump to intruders.