28 lines
1.3 KiB
Plaintext
28 lines
1.3 KiB
Plaintext
== XSS defense
|
|
|
|
|
|
=== Why?
|
|
Hopefully, we have covered that by now. Bottom line, you do not want someone else's code running in the context of your users and their logged-in session
|
|
|
|
=== What to encode?
|
|
The basic premise of defending against XSS is *output encoding* any untrusted input to the screen.
|
|
That may be changing with more sophisticated attacks, but it is still the best defense we currently have. *AND* ... *context matters*
|
|
|
|
Another word on 'untrusted input.' If in doubt, treat everything (even data you populated in your DB as untrusted).
|
|
Sometimes data is shared across multiple systems, and what you think is your data may not have been created by you/your team.
|
|
|
|
=== When/Where?
|
|
Encode *as the data is sent to the browser* (not in your persisted data). In the case of *Single Page Apps (SPA's), you will need to encode
|
|
in the client*. Consult your framework/library for details, but some resources will be provided on the next page.
|
|
|
|
=== How?
|
|
|
|
* Encode as HTML Entities in HTML Body
|
|
* Encode as HTML Entities in HTML Attribute
|
|
* Encode for JavaScript if outputting user input to JavaScript (but think about that ... you are outputting user input into JavaScript on your page!!)
|
|
|
|
*DO NOT* try to blacklist/negative filter on strings like '<script>' and so forth.
|
|
|
|
|
|
...See the next page for some recommended resources and reading on defending against XSS
|