Blog / WordPress/ Fixing Common 360 Website Security Scan Issues for WordPress

Fixing Common 360 Website Security Scan Issues for WordPress

wordpress如何解决360网站安全检测提示Flash配置不当漏洞-Cookie没有HttpOnly标志-发现robots.txt文件-X-Frame-Options头未设置

Common 360 Website Security Scan Issues and Solutions

When scanning a WordPress site with the 360 Website Security Detection tool, you may encounter several common warnings that lower your security score. This article provides specific solutions and configuration methods for these issues.

Issue 1: Flash Misconfiguration Vulnerability

Risk: Potential for 'unauthorized reading of user information,' reducing security by 20% (Severe).

Description: The crossdomain.xml file is configured too permissively, allowing cross-domain access from any domain, creating a security risk.

Solution:

  1. Locate the crossdomain.xml file on your server. On Linux, use:
    find / -name crossdomain.xml
  2. Edit the file to restrict overly permissive settings. A typical insecure configuration is:
    <?xml version="1.0"?>
    <!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
    <cross-domain-policy>
        <site-control permitted-cross-domain-policies="all"/>
        <allow-access-from domain="*" secure="false"/>
        <allow-http-request-headers-from domain="*" headers="*"/>
    </cross-domain-policy>
  3. Modify it to allow only your own domain (replace example.com with your actual domain):
    <?xml version="1.0"?>
    <!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
    <cross-domain-policy>
        <site-control permitted-cross-domain-policies="all"/>
        <allow-access-from domain="example.com" secure="false"/>
        <allow-http-request-headers-from domain="*" headers="*"/>
    </cross-domain-policy>

Issue 2: Cookie Missing HttpOnly Flag

Risk: Potential for 'website sensitive information leakage,' reducing security by 5% (Minor).

Description: Cookies are not set with the HttpOnly attribute, making them accessible to client-side scripts (like JavaScript) and increasing XSS attack risk.

Solution: Enable the session.cookie_httponly option in your php.ini file.

  1. Find the following line in php.ini:
    ; Whether or not to add the httpOnly flag to the cookie...
    session.cookie_httponly =
  2. Change it to:
    session.cookie_httponly = 1

Note: Restart your web server (Apache/Nginx) or PHP-FPM service for changes to take effect.

Issue 3: Discovery of robots.txt File

Risk: Potential for 'server configuration information leakage,' reducing security by 5% (Minor).

Description: The robots.txt file can expose site directory structures or sensitive paths, which could be exploited.

Solution: Configure your web server to restrict access to robots.txt for non-search-engine crawlers. For Nginx, add this to your site configuration (e.g., in a server block):

location = /robots.txt {
    if ($http_user_agent !~* "spider|bot|Python-urllib|pycurl") {
        return 403;
    }
}

This checks the User-Agent; if it's not a known crawler, a 403 Forbidden status is returned.

Issue 4: X-Frame-Options Header Not Set

Risk: Potential for 'unauthorized reading of user information,' reducing security by 5% (Minor).

Description: Missing the X-Frame-Options response header allows the site to be embedded in iframes on other sites, enabling clickjacking attacks.

Solution: Set the X-Frame-Options header to SAMEORIGIN (allowing framing only by pages from the same origin).

  • Apache: Add to .htaccess or virtual host config:
    Header always append X-Frame-Options SAMEORIGIN
  • Nginx: Add to server or location block:
    add_header X-Frame-Options SAMEORIGIN;
  • IIS: Add to Web.config within <system.webServer>:
    <httpProtocol>
      <customHeaders>
        <add name="X-Frame-Options" value="SAMEORIGIN" />
      </customHeaders>
    </httpProtocol>

Note: Modern browsers prefer the Content-Security-Policy header with the frame-ancestors directive for finer control, e.g., Content-Security-Policy: frame-ancestors 'self';.

Summary and Verification

After applying these changes, restart your web server. Re-scan your site with the 360 tool to verify fixes and see an improved security score.

Common Web Security Vulnerability Types

Beyond the specific issues above, understanding broader vulnerability categories helps build a more robust defense.

1. Injection Vulnerabilities

  • SQL Injection
  • Cross-Site Scripting (XSS)
  • HTTP Header Injection
  • Open Redirects
  • XML Injection

2. Information Disclosure

  • phpinfo() Exposure
  • Test/Backup File Leakage
  • Version Control File Exposure
  • Admin Interface Leakage
  • Error Detail Leakage
  • Credential Stuffing Attacks

3. Request Forgery

  • Cross-Site Request Forgery (CSRF)

4. Access Control Flaws

  • Unrestricted File Upload
  • Misconfigured crossdomain.xml
  • Insecure Cookie Flags (Missing Secure/HttpOnly)

5. Other Attack Vectors

  • Hash Collision (HashDoS)
  • SMS/Email Bombing

Regular security scans, keeping systems/plugins updated, and following secure coding practices are essential for maintaining WordPress site security.

Post a Comment

Your email will not be published. Required fields are marked with *.