EICAR test file

[jachymb]

https://en.wikipedia.org/wiki/EICAR_test_file

standard string that is interpreted as virus by anti-virus software:

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

[mjustin]

This is explicitly called out in the README as a string that should not be included in the list:

Likewise, please do not send pull requests which compromise manual usability of the file. This includes the EICAR test string, which can cause the file to be flagged by antivirus scanners, and files which alter the encoding of blns.txt.

That said, I wonder if there is a different mechanism for including strings like this, perhaps in a different file, so that the main file's usability won't be affected.

[ChipWolf]

It shouldn't matter keeping the string in the file, it qualifies as a 'naughty string' as far as I'm concerned. If it's flagged by A/V, then so be it; that's what it's designed to do. A separate file for strings that can be tagged as malicious only reduces usability as you'd have to combine the files in order to run a full test.

[rmunn]

The EICAR intended use page states, "Any anti-virus product that supports the EICAR test file should detect it in any file providing that the file starts with the following 68 characters, and is exactly 68 bytes long:" (and the EICAR test string follows immediately after that text).

So if including the EICAR test string causes the blns.txt file to be detected by anti-virus software, then that software is NOT complying with the EICAR recommendations (which say, in essence, "Only detect this string if it's the only thing in the file").

However, I wouldn't be at all surprised to find that there DOES exist quite a bit of anti-virus software that isn't behaving correctly, and flags a file containing the EICAR string plus other content before and after it as being a virus. If that's the case, then I'm :-1: on @ChipWolf's suggestion to include it.

[ssokolow]

Wouldn't that be like :-1:-ing a test for "UTF-8 file containing BOM in a position other than the first two bytes" because some badly-written text-processing utilities can't handle it?

I don't want to forget to feed embedded EICAR strings through my functional tests because it might catch a case where all it takes to DoS a site is for some troll to post the EICAR string in a comment, setting off some non-compliant traffic scanner appliance.

(eg. The troll posts it from home and then everyone visiting the site from work or other more heavily managed networks gets blocked. It's bad enough that there was so much trouble using custom fonts (eg. icon fonts) because network security appliances tended to strip the CORS headers needed for cross-domain @font-face.)

Until it showed up here, it never even occurred to me that something like the EICAR string might exist. Imagine how many other developers like me will continue to show up after this discussion has faded from memory.

[ChipWolf]

I am still of the opinion the EICAR test string is a naughty string, well within the scope of this project. We do not meet the EICAR test string's detection requirements because it is not the only string in the file, but it still remains useful for testing.

[rmunn]

@ChipWolf - This is the second time you've stated that the EICAR test string is (already?) in the blns. (Once here, and once in PR #133). Where is it? I don't see it anywhere in blns.txt or blns.json.

[ChipWolf]

@rmunn I must have been mistaken. Removed those comments It's either that or someone rebased it out