Proposal: High-legibility fonts requirement

[narfbg]

Fairly self-explanatory, branch off from #3338 and more specifically first mention here.

Draft requirement:

Verify that fonts used to display user-provided data are highly legible, as to resist visual spoofing through lookalike characters. This also applies to e-mail templates and printer device output.

And if appropriate, supplementary section guidance text:

User-provided text can be leveraged for phishing and similar methods for fraud. Attackers often exploit lookalike characters such as the letter O and the digit 0, or combinations such as "rn" mimicking the letter "m". While this is especially common with hyperlinks, visual spoofing attacks are not limited to functional elements and applications should account for that. The Sans-serif family of fonts is typically a safe choice for limiting the potential for exploitation.

I kind of wish to also mention the WCAG as a natural overlap, since symbiosis with other standards usually benefits security indirectly. I fear that it's getting too detailed already though.

Thoughts?

[elarlang]

Areas to think further

• Although kind of covered and there is no other use for fonts than human-readable output, I would propose something like "Verify that fonts used human-readable output (web output, emails, generated documents)"
• "display user-provided data" - the user-provided data is the source of spoofing, but should we limit the requirement to it? If the application shows its own "non-user-provided data" in a non-readable way, it is also problematic. Is it a proper security risk or an usability issue, is another question.

My concern is also - how one can verify that, is it "ok" or is it "not ok". What is the metric to provide a clear decision?

[narfbg]

• Although kind of covered and there is no other use for fonts than human-readable output, I would propose something like "Verify that fonts used human-readable output (web output, emails, generated documents)"

That might open the door for "this is for AI agents and not humans" kind of reasoning and impede humans' ability for review. Did you mean for that to be just more elegant wording? I'd thought of refering to UI as a similar shorthand, but couldn't come up with a good version.

• "display user-provided data" - the user-provided data is the source of spoofing, but should we limit the requirement to it? If the application shows its own "non-user-provided data" in a non-readable way, it is also problematic. Is it a proper security risk or an usability issue, is another question.

I was actually pondering the same thing and am not opposed to it, but "why not" is rarely a good reason on its own and so I decided to err on the side of specificity. Also to avoid overreach and not create unnecessary conflicts between security and UX teams.

My concern is also - how one can verify that, is it "ok" or is it "not ok". What is the metric to provide a clear decision?

I couldn't figure that out ... Typography shouldn't be hard to measure, technically, but the ways to do that are unlikely to be practical or easily explainable within an ASVS requirement.

[elarlang]

Did you mean for that to be just more elegant wording? I'd thought of refering to UI as a similar shorthand, but couldn't come up with a good version.

My idea is kind of to open a wider specter than the UI - whatever the application prodoces (web output, email, documents in whatever format), they all must be readable without guessing, "is it zero 0 or letter O.

So this is for sure something to keep in mind when developing, my concern is whether it is a suitable verifiable and/or security requirement in ASVS.

[narfbg]

It should apply to all output indeed, I'm sure we can agree on better wording in that regard.

On your concerns ... I don't think there's reasonable doubt about it being a security requirement. Not a traditional concern, sure, but the guidance text I provided makes the security rationale clear. The verifiable question is the big one.

I did some research and unfortunately there's no easy answer to that, since it's fundamentally about humans' ability to read. The closest thing I found to a programmatically verifiable Yes/No is the "Gaussian Blur" test (hard to explain, easy to google) - if OCR technology can recognize slighly blurred text (i.e. match to input), then it should also be considered legible by humans.

Whether that's practical is a different question.