1. Data Validation
Data validation is the process of ensuring that your application is running with correct data. If your PHP script expects an integer for user input, then any other type of data would be discarded. Every piece of user data must be validated when it is received to ensure it is of the corrected type, and discarded if it doesn’t pass the validation process.
2. Data Sanitization
Data sanitization focuses on manipulating the data to make sure it is safe by removing any unwanted bits from the data and normalizing it to the correct form
3. Encoding
Encoding is the act of escaping user input so that the browser interprets it only as data, not as code. The most recognizable type of encoding in web development is HTML escaping, which converts characters like < and > into < and >, respectively.
The following pseudocode is an example of how user input could be encoded using HTML escaping and then inserted into a page by a server-side script:
print "<html>"
print "Latest comment: "
print encodeHtml(userInput)
print "</html>"
If the user input were the string <script>...</script>, the resulting HTML would be as follows:
<html>
Latest comment:
<script>...</script>
</html>
Because all characters with special meaning have been escaped, the browser will not parse any part of the user input as HTML.
4. Auto-Escaping and Context-Aware Escaping templates
Sometimes it is advantageous to have everything assigned to Smarty automatically HTML-escaped to reduce the risks of XSS (cross-site scripting) vulnerabilities.
5. Content-security policy
Content-security policy is as a source whitelist. Typically when we make a request for a web page, our browsers trusts output that the server is delivering. CSP limits this trust model by sending Content-Security-Policy header that allows the application to specify a whitelist of trusted (expected) sources. When the browser receives this header, it will only render or execute resources from those sources.
In the event that an attacker does have the ability to inject malicious content that is reflected back against the user, the script will not match the whitelist, and will not be executed.
Example 1: A server wishes to load resources only from its own origin:
Content-Security-Policy: default-src 'self'
Example 2: An auction site wishes to load images from any URI, plugin content from a list of trusted media providers (including a content distribution network), and scripts only from a server under its control hosting sanitized ECMAScript:
Content-Security-Policy: default-src 'self'; img-src *; object-src media1.example.com media2.example.com *.cdn.example.com; script-src trustedscripts.example.com
Example 3: Online banking site wishes to ensure that all of the content in its pages is loaded over TLS to prevent attackers from eavesdropping on insecure content requests:
Content-Security-Policy: default-src https: 'unsafe-inline' 'unsafe-eval'
Example 4: A website that relies on inline script elements wishes to ensure that script is only executed from its own origin, and those elements it intentionally inserted inline:
Content-Security-Policy: script-src 'self' 'nonce-$RANDOM';
The inline script elements would then only execute if they contained a matching nonce attribute: <script nonce="$RANDOM">...</script>
6. Javascript sandbox tools
7. Cookie security
Many web applications tie session cookies to the IP address of the user who originally logged in, and only permit that IP to use that cookie. This is effective in situations like if an attacker is only after the cookie
HTTP-only cookies: Http-Only flag allows a web server to set a cookie that is unavailable to client-side scripts. It disables client access via document.cookie and mitigates cookie theft via XSS
8. Application Firewall
By installing a third party application firewall, which intercepts XSS attacks before they reach the web server and the vulnerable scripts, and blocks them. For each input source, the application firewall inspects the data against various HTML tag patterns and Javascript patterns, and if any match, the request is rejected and the malicious input does not arrive to the server.
A full detailed guide to prevent XSS is also available on OWASP. You can read it here.
Data validation is the process of ensuring that your application is running with correct data. If your PHP script expects an integer for user input, then any other type of data would be discarded. Every piece of user data must be validated when it is received to ensure it is of the corrected type, and discarded if it doesn’t pass the validation process.
2. Data Sanitization
Data sanitization focuses on manipulating the data to make sure it is safe by removing any unwanted bits from the data and normalizing it to the correct form
3. Encoding
Encoding is the act of escaping user input so that the browser interprets it only as data, not as code. The most recognizable type of encoding in web development is HTML escaping, which converts characters like < and > into < and >, respectively.
The following pseudocode is an example of how user input could be encoded using HTML escaping and then inserted into a page by a server-side script:
print "<html>"
print "Latest comment: "
print encodeHtml(userInput)
print "</html>"
If the user input were the string <script>...</script>, the resulting HTML would be as follows:
<html>
Latest comment:
<script>...</script>
</html>
Because all characters with special meaning have been escaped, the browser will not parse any part of the user input as HTML.
4. Auto-Escaping and Context-Aware Escaping templates
Sometimes it is advantageous to have everything assigned to Smarty automatically HTML-escaped to reduce the risks of XSS (cross-site scripting) vulnerabilities.
5. Content-security policy
Content-security policy is as a source whitelist. Typically when we make a request for a web page, our browsers trusts output that the server is delivering. CSP limits this trust model by sending Content-Security-Policy header that allows the application to specify a whitelist of trusted (expected) sources. When the browser receives this header, it will only render or execute resources from those sources.
In the event that an attacker does have the ability to inject malicious content that is reflected back against the user, the script will not match the whitelist, and will not be executed.
Example 1: A server wishes to load resources only from its own origin:
Content-Security-Policy: default-src 'self'
Example 2: An auction site wishes to load images from any URI, plugin content from a list of trusted media providers (including a content distribution network), and scripts only from a server under its control hosting sanitized ECMAScript:
Content-Security-Policy: default-src 'self'; img-src *; object-src media1.example.com media2.example.com *.cdn.example.com; script-src trustedscripts.example.com
Example 3: Online banking site wishes to ensure that all of the content in its pages is loaded over TLS to prevent attackers from eavesdropping on insecure content requests:
Content-Security-Policy: default-src https: 'unsafe-inline' 'unsafe-eval'
Example 4: A website that relies on inline script elements wishes to ensure that script is only executed from its own origin, and those elements it intentionally inserted inline:
Content-Security-Policy: script-src 'self' 'nonce-$RANDOM';
The inline script elements would then only execute if they contained a matching nonce attribute: <script nonce="$RANDOM">...</script>
6. Javascript sandbox tools
7. Cookie security
Many web applications tie session cookies to the IP address of the user who originally logged in, and only permit that IP to use that cookie. This is effective in situations like if an attacker is only after the cookie
HTTP-only cookies: Http-Only flag allows a web server to set a cookie that is unavailable to client-side scripts. It disables client access via document.cookie and mitigates cookie theft via XSS
8. Application Firewall
By installing a third party application firewall, which intercepts XSS attacks before they reach the web server and the vulnerable scripts, and blocks them. For each input source, the application firewall inspects the data against various HTML tag patterns and Javascript patterns, and if any match, the request is rejected and the malicious input does not arrive to the server.
A full detailed guide to prevent XSS is also available on OWASP. You can read it here.
%2Bdork%2Blist%2Binfosec%2Baffairs.png)
No comments:
Post a Comment