Although at first it might look that on a browser the concept of attack surface doesn’t matter, unless you are building a pure html website with NO Javascript, you will also need to consider the attack surface of your code.
The attack surface is basically the ways the code execution can be affected/influenced by an attacker’s data/actions
For Javascript code that is running on browser there are three main sources of malicious data
1) data provided by browser (such as url, hash, cookies, local storage)
2) data received from the server (embedded on page or via AJAX calls)
3) 3rd party scripts (like the ones used for Analytics and Ads)
The impact of malicious data will depend on where/how that data is used, namely if that data ‘becomes code'.
The choice of JS framework will make a massive difference (for example jQuery is really dangerous and AngularJS can be much safer). Using security measures like CSP (Content Security Policies) will also make a massive difference (since it reduces the locations where Javascript can execute).
The best places to start when mapping the attack surface of client side code is to answer these questions:
- Is the URL or Hash value provided by the Browser used in the application? If so where?
- What are all the locations where data enters the application?
- Cookies
- Local storage
- Ajax calls
- Is there any dynamic DOM creation?
- Is .html() used anywhere? (.text is much safer)
- Is HTML currently received from the server and dynamically inserted into the DOM?
- What 3rd party scripts are used and what are they doing?
- Where do these scripts come from?
- Do the original 3rd party scripts load more scripts dynamically?
Note that from the client-side code’s point of view, its ‘own application server' is one of the potential attackers, i.e. the client must not trust the data that is received from the server, and must ensure that all rendered data is correctly encoded in context.
Initially these mappings can be done manually, but a key objective is to calculate them using scripts (i.e. programatically), so that a baseline is kept, and security focused unit-tests can be written
Some extra additional reading on this topic
- https://www.owasp.org/index.php/Attack_Surface_Analysis_Cheat_Sheet
- http://testlab.sit.fraunhofer.de/downloads/Publications/heumann-quantifying_the_attack_surface_of_a_web_application-GI_Sicherheit_2010.pdf
- https://www.blackhat.com/docs/us-15/materials/us-15-Yason-Understanding-The-Attack-Surface-And-Attack-Resilience-Of-Project-Spartans-New-EdgeHTML-Rendering-Engine-wp.pdf
- http://www.cs.cmu.edu/~pratyus/tse10.pdf
- http://www.cs.colostate.edu/~malaiya/635/09/Howard03.pdf
