Whilst Reflected and Stored XSS can generally be addressed through server-side user input encoding (such as through the PHP htmlentities() function) or with browser protections such as Content-Security-Policy – this is not sufficient for DOM-XSS.
Where a dangerous function is used, user input into that function should be limited through user input filtering. An allow-list approach of restricting user input to only known-good input should be used. For example, limiting input to the smallest number of characters possible (such as alphanumerics only) and checking the expected data type (such as limiting input to integers only). This is in contrast to a block-list of known-bad inputs being blocked, which is often less effective due to the large degree of flexibility that JavaScript allows. For a good example of this flexibility, consider something like JScrewIt.
Furthermore, dangerous functions such as eval() should be entirely avoided. The Mozilla Developer Network describes eval() as “an enormous security risk”. Their page has an entire section titled “Never use eval()!”
That’s it!
Read More
Finding SQL Injection
Introduction SQL Injection is an old vulnerability; first published on Christmas Day 1998 in Phrack Magazine 54. The issue occurs where user supplied input is insecurely concatenated into an SQL query. It generally allows a threat actor to perform any of the operations that the database user can execute – such as extracting, [...]| Play | Cover | Release Label |
Track Title Track Authors |
|---|