"When you set a max length on a form field or API, you expect it to hold. But what if a four-character string could secretly carry 10,000 extra bytes of invisible data, crashing your database or bypassing your validation? That was the vulnerability I found and fixed in the popular JavaScript library validator. It was a subtle bug involving Unicode Variation Selectors that allowed attackers to inject massive payloads while still passing length checks."
"JavaScript strings use UTF‑16. Some visible "characters" span two code units (surrogate pairs). isLength adjusts for that. It treats a base character plus a Variation Selector as one perceived character. That's because the selector only changes the presentation. // Emoji still count as one perceived character const smile = '🙂'; console.log(smile.length); // 2 (UTF-16 code units) // With isLength, it's treated as 1"
A popular JavaScript validation library's isLength function compared character counts to limits but misinterpreted Unicode. JavaScript uses UTF-16 where some visible characters occupy multiple code units or combine with Variation Selectors. The function treated base characters plus Variation Selectors as a single perceived character and subtracted selectors from length checks. Attackers could append thousands of zero-width Variation Selectors to a short string, increasing storage length while passing max-length validation. This could cause database truncation, performance degradation, or enable large payload injection. Proper handling requires counting stored code units or sanitizing/removing excessive selectors.
Read at Droids On Roids
Unable to calculate read time
Collection
[
|
...
]