如果您的用户输入为 病态，规范化将无济于事。 。

有关如何处理不规则序列的更多信息，转换过程，位于Unicode 5.2中的第3.9节，Unicode编码表格

对于这些情况，请将无效序列替换为replacement char U + FFFD 。这是一个神奇的药丸，将工作在99.9％的情况下，但0.1％剩下足以破坏你的数据库。

为了真正安全，你需要完全分析您的输入解析器，查看它们是否容易受到 U + FFFD 替换的影响。

strong> ***的解决方案是停止解析，清理垃圾，然后返回错误消息。

We upgraded our security scanner recently, and it's reporting a new issue.

What's the recommended fix? (We happen to be on ACF9.)

(Also, if you have an example exploit geared to CF, I'd appreciate it.)

---

Unicode transformation issues

Severity

High

Type

Configuration

Reported by module

Scripting (XSS.script)

Description

This page is vulnerable to various Unicode transformation issues such as Best-Fit Mappings, Overlong byte sequences, Ill-formed sequences.

Best-Fit Mappings occurs when a character X gets transformed to an entirely different character Y. In general, best-fit mappings occur when characters are transcoded between Unicode and another encoding.

Overlong byte sequences (non-shortest form) - UTF-8 allows for different representations of characters that also have a shorter form. For security reasons, a UTF-8 decoder must not accept UTF-8 sequences that are longer than necessary to encode a character. For example, the character U+000A (line feed) must be accepted from a UTF-8 stream only in the form 0x0A, but not in any of the following five possible overlong forms:

• 0xC0 0x8A

• 0xE0 0x80 0x8A

• 0xF0 0x80 0x80 0x8A

• 0xF8 0x80 0x80 0x80 0x8A

• 0xFC 0x80 0x80 0x80 0x80 0x8A

Ill-Formed Subsequences As REQUIRED by UNICODE 3.0, and noted in the Unicode Technical Report #36, if a leading byte is followed by an invalid successor byte, then it should NOT consume it.

Impact

Software vulnerabilities arise when Best-Fit mappings occur. For example, characters can be manipulated to bypass string handling filters, such as cross-site scripting (XSS) or SQL Injection filters, WAF's, and IDS devices. Overlong UTF-8 sequence could be abused to bypass UTF-8 substring tests that look only for the shortest possible encoding.

Recommendation

Identiy the source of these Unicode transformation issues and fix them. Consult the web references bellow for more information.

References

Unicode Security

UTF-8 and Unicode FAQ for Unix/Linux

A couple of unicode issues on PHP and Firefox

Unicode Security Considerations

Affecteditems

/mysite-portal/

Details

URL encoded POST input linkServID was set to acu5955%EF%BC%9Cs1%EF%B9%A5s2%CA%BAs3%CA%B9uca5955

List of issues:

• Unicode character U+02B9 MODIFIER LETTER PRIME (encoded as %CA%B9) was transformed into U+0027 APOSTROPHE (')

• Unicode character U+02B9 MODIFIER LETTER PRIME (encoded as %CA%B9) was transf ... (line truncated)

Request headers

GET

/mysite-portal/?display=login&status=failed&rememberMe=0&contentid=&LinkServID=acu5955%1 Cs1es2%BAs3%B9uca5955&returnURL=https://stage-cms.mysite.com/mysite-portal/ HTTP/1.1 Referer: https://stage-cms.mysite.com:443/

Connection: Keep-alive

Accept-Encoding: gzip,deflate

User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)

Accept: */*

Host: stage-cms.mysite.com

Canonicalization wouldn't help you if your user inputs are ill-formed sequence.

For more information on how to handle ill-formed subsequences, see "Constraints on Conversion Processes" in Section 3.9, Unicode Encoding Forms in Unicode 5.2

For those cases, replace the invalid sequences with the "replacement char" U+FFFD built exactly for this purpose. That's the magic pill that will work in 99.9% cases but that 0.1% left is enough to wipeout your databases.

To be really secure, you need to fully analyze your input parsers to see if they're vulnerable against U+FFFD replacements.

The best solution that works all the time is to stop parsing, cleanup your junk, and then return an error message.