Application Security for frontend OWASP

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.