The new AFC is blocking a nightly report that comes in HTML format with
javascript in it -- as I would expect, but before his new AFC, they were
erroneously slipping through.

I don't know why these reports weren't being blocked before, it's basic
HTML with a short block of javascript at the end.  Of note, the javascript
starts like this and has a base64 image in its code - something that the
new AFC addresses:

<script type="text/javascript">
    var iX = 0; var iY = 0; var iX = 0; var iY = 0;
    var charting_img = "*data**:image/gif;base64*, -- base 64 is here in
real code ==";
    var iCurrent = "";
    var images = document.getElementsByTagName('imgs');

So it looks like the new AFC works much better.  Great.

Now I need an exception to allow these nightly reports through again.
Ordinarily, I'd allow the sha256 of the detected blocked *file* to allow
the code through, but in looking at the logs, it appears that it is showing
the sha256 of the .html file itself vs just the portion of javascript that
is being detected.  That means that the sha256 that shows in the log is
different each time and can't be use for the exception.

*Is there a way that I can allow the javascript code (which is constant and
in an ever changing html file) through using sha256 or another method, but
still block all other html files with javascript embedded?*

I don't have control of the sending server.  I know I don't want to use a
UserAttach exception for the sending email address, as that's used for many
other messages (frustratingly so).

I don't want an exception to allow html with javascript for the receiving
users regardless of the sender, that would be too much of a risk.

Thanks
_______________________________________________
Assp-test mailing list
Assp-test@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/assp-test

Reply via email to