You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by "Sharma, Ashish" <as...@hp.com> on 2013/03/06 11:20:52 UTC
Checking for email attachment name for containing Javscript code
that could get potentially executed when displayed on a webpage.
All,
I have a mail receiving server that parses incoming emails for email attachment and the files are listed on a web page for users to see.
Here I need to check for email attachment name for containing Javscript code that could get potentially executed when displayed on a webpage.
Is there a way in Spamassassin conf that can help me in testing for the above mentioned scenario?
Thanks
Ashish Sharma
RE: Checking for email attachment name for containing Javscript
code that could get potentially executed when displayed on a webpage.
Posted by Benny Pedersen <me...@junc.eu>.
Sharma, Ashish skrev den 2013-03-08 15:05:
> The attachment name contains the javascript code at the bottom of the
> pasted file.
extracttext plugin ?, so bayes learning javascript attachments ?
Re: Checking for email attachment name for containing Javscript code
that could get potentially executed when displayed on a webpage.
Posted by John Hardin <jh...@impsec.org>.
On Fri, 22 Mar 2013, David F. Skoll wrote:
> On Fri, 22 Mar 2013 07:21:25 -0700 (PDT)
> John Hardin <jh...@impsec.org> wrote:
>
>> I suggested HTML-escaping the attachment filenames during the page
>> generation as the standard solution
>
> Well, yes. Any content that lands on your doorstep needs to be treated
> carefully. :)
>
>> but I think there's still a desire to prevent suspicious content
>> from getting that far in the first place.
>
> Sure, but trying to determine all the possible attack vectors is futile.
> Better just to make your code robust by HTML-escaping everything before
> sending it to the browser.
Which was exactly the point I made, but the OP wasn't convinced.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Maxim V: Close air support and friendly fire should be easier to
tell apart.
-----------------------------------------------------------------------
295 days since the first successful private support mission to ISS (SpaceX)
Re: Checking for email attachment name for containing Javscript
code that could get potentially executed when displayed on a webpage.
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Fri, 22 Mar 2013 07:21:25 -0700 (PDT)
John Hardin <jh...@impsec.org> wrote:
> I suggested HTML-escaping the attachment filenames during the page
> generation as the standard solution
Well, yes. Any content that lands on your doorstep needs to be treated
carefully. :)
> but I think there's still a desire to prevent suspicious content
> from getting that far in the first place.
Sure, but trying to determine all the possible attack vectors is futile.
Better just to make your code robust by HTML-escaping everything before
sending it to the browser.
Regards,
David.
Re: Checking for email attachment name for containing Javscript code
that could get potentially executed when displayed on a webpage.
Posted by John Hardin <jh...@impsec.org>.
On Fri, 22 Mar 2013, David F. Skoll wrote:
> On Fri, 22 Mar 2013 13:47:16 +0000
> Martin Gregorie <ma...@gregorie.org> wrote:
>
>> On Thu, 2013-03-21 at 09:40 +0000, Sharma, Ashish wrote:
>>> http://pastebin.com/FLjzCsUZ
>
>> What's the problem with this message?
>
> If you base64-decode the filename PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0PnRlcy50eHQ=
> you get <script>alert(1)</script>tes.txt
>
> However, any mail reader should be hardened against accepting arbitrary
> filenames... I can't see how this would be a problem in practice except
> maybe in badly-written webmail systems.
The OP has a tool that posts a web page with the attachment filenames as
the descriptive text for a link to the extracted attachment. He's worried
about attacks against his users via that page.
I suggested HTML-escaping the attachment filenames during the page
generation as the standard solution but I think there's still a desire to
prevent suspicious content from getting that far in the first place.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Maxim V: Close air support and friendly fire should be easier to
tell apart.
-----------------------------------------------------------------------
295 days since the first successful private support mission to ISS (SpaceX)
Re: Checking for email attachment name for containing Javscript
code that could get potentially executed when displayed on a webpage.
Posted by Martin Gregorie <ma...@gregorie.org>.
On Fri, 2013-03-22 at 11:04 -0700, John Hardin wrote:
> On Fri, 22 Mar 2013, Martin Gregorie wrote:
>
> > On Fri, 2013-03-22 at 09:56 -0400, David F. Skoll wrote:
> >
> >> However, any mail reader should be hardened against accepting arbitrary
> >> filenames... I can't see how this would be a problem in practice except
> >> maybe in badly-written webmail systems.
> >
> > Agreed.
> >
> > I don't recall anybody naming such a badly written MUA or web-MUA.
> > Anybody?
>
> See my earlier comments on the OP's original request elsewhere in this
> thread.
>
I saw them and agree with you.
I asked because I wanted to see if anybody could name specific programs
that were known to fall victim to this sort of mal-formed message.
Martin
Re: Checking for email attachment name for containing Javscript code
that could get potentially executed when displayed on a webpage.
Posted by John Hardin <jh...@impsec.org>.
On Fri, 22 Mar 2013, Martin Gregorie wrote:
> On Fri, 2013-03-22 at 09:56 -0400, David F. Skoll wrote:
>
>> However, any mail reader should be hardened against accepting arbitrary
>> filenames... I can't see how this would be a problem in practice except
>> maybe in badly-written webmail systems.
>
> Agreed.
>
> I don't recall anybody naming such a badly written MUA or web-MUA.
> Anybody?
See my earlier comments on the OP's original request elsewhere in this
thread.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Phobias should not be the basis for laws.
-----------------------------------------------------------------------
295 days since the first successful private support mission to ISS (SpaceX)
Re: Checking for email attachment name for containing Javscript
code that could get potentially executed when displayed on a webpage.
Posted by Martin Gregorie <ma...@gregorie.org>.
On Fri, 2013-03-22 at 09:56 -0400, David F. Skoll wrote:
> On Fri, 22 Mar 2013 13:47:16 +0000
> Martin Gregorie <ma...@gregorie.org> wrote:
>
> > On Thu, 2013-03-21 at 09:40 +0000, Sharma, Ashish wrote:
> > > http://pastebin.com/FLjzCsUZ
>
> > What's the problem with this message?
>
> If you base64-decode the filename PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0PnRlcy50eHQ=
> you get <script>alert(1)</script>tes.txt
>
Thanks for the hint - I didn't think of that because of the UTF8 prefix,
despite it not looking like typical untranslated UTF8, and didn't
realise I had a base 64 decoder (I've since found the base64 utility -
isn't 'apropos' wonderful?).
> However, any mail reader should be hardened against accepting arbitrary
> filenames... I can't see how this would be a problem in practice except
> maybe in badly-written webmail systems.
>
Agreed.
I don't recall anybody naming such a badly written MUA or web-MUA.
Anybody?
Martin
Re: Checking for email attachment name for containing Javscript
code that could get potentially executed when displayed on a webpage.
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Fri, 22 Mar 2013 13:47:16 +0000
Martin Gregorie <ma...@gregorie.org> wrote:
> On Thu, 2013-03-21 at 09:40 +0000, Sharma, Ashish wrote:
> > http://pastebin.com/FLjzCsUZ
> What's the problem with this message?
If you base64-decode the filename PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0PnRlcy50eHQ=
you get <script>alert(1)</script>tes.txt
However, any mail reader should be hardened against accepting arbitrary
filenames... I can't see how this would be a problem in practice except
maybe in badly-written webmail systems.
Regards,
David.
FW: Checking for email attachment name for containing Javscript
code that could get potentially executed when displayed on a webpage.
Posted by "Sharma, Ashish" <as...@hp.com>.
On Sun, 2013-03-24 at 11:05 +0000, Sharma, Ashish wrote:
> I have encoded the harmful filename '<script>alert(1)</script>tes.txt'
> to base64 and added them into the email as it's allowed as per RFC
> 2047 in email headers and is a valid form.
>
> This is bypassing the spam rule that you created earlier and posted.
>
In that case it looks as though the MimeHeader plugin doesn't recognise
base64 encoded values for names or filenames and doesn't decode them.
I didn't write or maintain the MIMEHeader plugin: I just use it. If this is a major issue for your mail stream, I suggest you raise a bug against the plugin requesting that RFC 2047 compliance be implemented.
> as I could not find relevant spamassassin documentation on 'mimeheader'.
>
I would agree that the plugin's documentation is minimal: I would not have been able to use it if some kind person hadn't posted example rules on this list.
Martin
Re: Checking for email attachment name for containing Javscript
code that could get potentially executed when displayed on a webpage.
Posted by Martin Gregorie <ma...@gregorie.org>.
On Thu, 2013-03-21 at 09:40 +0000, Sharma, Ashish wrote:
> What would be the change in spam rule if the Content-Disposition field
> is mime word encoded as per RFC 2047 ?
>
> Please find the sample eml at:
>
> http://pastebin.com/FLjzCsUZ
>
What's the problem with this message? The portion you've posted contains
only text/plain and text/html parts: neither are harmful on the face of
it and, unlike the message my rule was meant to catch, neither the name
or the filename of the attachment are obviously executable or otherwise
harmful.
Did you obfuscate the various names and e-mail addresses in the message?
If so, you've probably removed anything that might be distinctive enough
to write rules against.
Martin
RE: Checking for email attachment name for containing Javscript
code that could get potentially executed when displayed on a webpage.
Posted by "Sharma, Ashish" <as...@hp.com>.
Martin,
What would be the change in spam rule if the Content-Disposition field is mime word encoded as per RFC 2047 ?
Please find the sample eml at:
http://pastebin.com/FLjzCsUZ
thanks
Ashish
-----Original Message-----
From: Martin Gregorie [mailto:martin@gregorie.org]
Sent: Sunday, March 10, 2013 2:46 AM
To: users@spamassassin.apache.org
Subject: Re: Checking for email attachment name for containing Javscript code that could get potentially executed when displayed on a webpage.
On Sat, 2013-03-09 at 20:56 +0000, Martin Gregorie wrote:
Correction:
> describe SCRIPTED_NAME Attachment name or filename is a script
> mimeheader __SCRIPTN1 Content-Type =~ /name.*\=.*<script>/
> mimeheader __SCRIPTN2 Content-Disposition =~ /filename.*\=.*<script>/
> meta SCRIPTED_NAME (__SCRIPTN1 || __SCRIPTN2)
> score SCRIPTED_NAME 6.0
>
>
I made an editing mistake when shortening the rule names so __SCRIPTN2
wouldn't wrap when posted. Grrrrr.
Martin
Re: Checking for email attachment name for containing Javscript
code that could get potentially executed when displayed on a webpage.
Posted by Martin Gregorie <ma...@gregorie.org>.
On Sat, 2013-03-09 at 20:56 +0000, Martin Gregorie wrote:
Correction:
> describe SCRIPTED_NAME Attachment name or filename is a script
> mimeheader __SCRIPTN1 Content-Type =~ /name.*\=.*<script>/
> mimeheader __SCRIPTN2 Content-Disposition =~ /filename.*\=.*<script>/
> meta SCRIPTED_NAME (__SCRIPTN1 || __SCRIPTN2)
> score SCRIPTED_NAME 6.0
>
>
I made an editing mistake when shortening the rule names so __SCRIPTN2
wouldn't wrap when posted. Grrrrr.
Martin
Re: Checking for email attachment name for containing Javscript
code that could get potentially executed when displayed on a webpage.
Posted by Martin Gregorie <ma...@gregorie.org>.
On Sat, 2013-03-09 at 09:23 -0800, John Hardin wrote:
> On Sat, 9 Mar 2013, Martin Gregorie wrote:
>
> > Presumably the, ahem, misguided js interpretation is being triggered by
> > the <script></script> tags, so wouldn't the regex I've used here
> >
> > mimeheader JS_TRAP_RULE name =~ /<script>/
> >
> > be a more general way of catching this sort of thing when its supplied
> > as the attachment name and/or file name?
>
> Yeah, that would be the best thing to look for.
>
In case anybody is interested, here's my resulting, tested rule:
describe SCRIPTED_NAME Attachment name or filename is a script
mimeheader __SCRIPTN1 Content-Type =~ /name.*\=.*<script>/
mimeheader __SCRIPTN2 Content-Disposition =~ /filename.*\=.*<script>/
meta SCRIPTED_NAME (__MG_SCRIPTN1 || __MG_SCRIPTN2)
score SCRIPTED_NAME 6.0
Martin
Re: Checking for email attachment name for containing Javscript
code that could get potentially executed when displayed on a webpage.
Posted by Martin Gregorie <ma...@gregorie.org>.
On Sat, 2013-03-09 at 09:23 -0800, John Hardin wrote:
> Regarding that analogy, SA is not an antivirus tool, and any attempt to
> make it one would be met with resistance. SA is also not an email
> *security* tool.
>
Agreed. If I thought I needed an antivirus tool I's run Clamav.
> An email security tool which has been around for a lot more than a decade
> and which stops attacks like this is the Email Sanitizer, which I wrote:
>
> http://www.impsec.org/email-tools/procmail-security.html
>
> If you're worried about javascript attacks via email, this has prevented
> them for a long time.
>
Bookmarked for future reference.
Martin
Re: Checking for email attachment name for containing Javscript code
that could get potentially executed when displayed on a webpage.
Posted by John Hardin <jh...@impsec.org>.
On Sat, 9 Mar 2013, Martin Gregorie wrote:
> On Sat, 2013-03-09 at 01:42 -0600, David B Funk wrote:
>> On Fri, 8 Mar 2013, John Hardin wrote:
>>
>>> I'll say it again: rather than trying to write SA rules that detect
>>> javascript in attachment filenames, why not just have the code that generates
>>> your web pages perform HTML escaping on all user-provided data that will be
>>> displayed (i.e., the attachment filenames)?
>>>
>>> In other words, the page generator would convert that attachment filename
>>> from "<script>document.write("Hello World");</script>.txt" to
>>> "<script>document.write("Hello World");</script>.txt"
>>>
>>> This is a simple, standard and robust solution to your problem that also
>>> prevents other attack vectors you haven't thought of yet.
>
> Presumably the, ahem, misguided js interpretation is being triggered by
> the <script></script> tags, so wouldn't the regex I've used here
>
> mimeheader JS_TRAP_RULE name =~ /<script>/
>
> be a more general way of catching this sort of thing when its supplied
> as the attachment name and/or file name?
Yeah, that would be the best thing to look for.
>> What if it ends up in some client's INBOX and they view it with a "very helpful"
>> client that processes the javascript, or if the client forwards the message
>> on to his friend's hotmail/yahoo/gmail/etc address?
>
> I'd call any MUA that would try to execute a name or file name "very
> badly written" rather than "very helpful".
Agreed.
> IMO this is no different from careless coding that enables SQL scripting
> attacks by using direct string execution rather than prepared statements
> in ODBC/JDBC to run queries containing user-supplied data. It should at
> least get the same response when discovered: raise a 'critical' category
> bug against the offending MUA and follow that up with exposure through
> CERT etc. if its not fixed PDQ.
Agreed again.
>> I run an AV scanner on our mailserver even though my Linux client isn't
>> susceptible to viri because stopping crap-ware is the right thing to do.
>
> Agreed.
Regarding that analogy, SA is not an antivirus tool, and any attempt to
make it one would be met with resistance. SA is also not an email
*security* tool.
An email security tool which has been around for a lot more than a decade
and which stops attacks like this is the Email Sanitizer, which I wrote:
http://www.impsec.org/email-tools/procmail-security.html
If you're worried about javascript attacks via email, this has prevented
them for a long time.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Failure to plan ahead on someone else's part does not constitute
an emergency on my part. -- David W. Barts in a.s.r
-----------------------------------------------------------------------
Tomorrow: Daylight Saving Time begins in U.S. - Spring Forward
Re: Checking for email attachment name for containing Javscript
code that could get potentially executed when displayed on a webpage.
Posted by Martin Gregorie <ma...@gregorie.org>.
On Sat, 2013-03-09 at 01:42 -0600, David B Funk wrote:
> On Fri, 8 Mar 2013, John Hardin wrote:
>
> > I'll say it again: rather than trying to write SA rules that detect
> > javascript in attachment filenames, why not just have the code that generates
> > your web pages perform HTML escaping on all user-provided data that will be
> > displayed (i.e., the attachment filenames)?
> >
> > In other words, the page generator would convert that attachment filename
> > from "<script>document.write("Hello World");</script>.txt" to
> > "<script>document.write("Hello World");</script>.txt"
> >
> > This is a simple, standard and robust solution to your problem that also
> > prevents other attack vectors you haven't thought of yet.
>
Presumably the, ahem, misguided js interpretation is being triggered by
the <script></script> tags, so wouldn't the regex I've used here
mimeheader JS_TRAP_RULE name =~ /<script>/
be a more general way of catching this sort of thing when its supplied
as the attachment name and/or file name?
> What if it ends up in some client's INBOX and they view it with a "very helpful"
> client that processes the javascript, or if the client forwards the message
> on to his friend's hotmail/yahoo/gmail/etc address?
>
I'd call any MUA that would try to execute a name or file name "very
badly written" rather than "very helpful".
IMO this is no different from careless coding that enables SQL scripting
attacks by using direct string execution rather than prepared statements
in ODBC/JDBC to run queries containing user-supplied data. It should at
least get the same response when discovered: raise a 'critical' category
bug against the offending MUA and follow that up with exposure through
CERT etc. if its not fixed PDQ.
> I run an AV scanner on our mailserver even though my Linux client isn't
> susceptible to viri because stopping crap-ware is the right thing to do.
>
Agreed.
Martin
RE: Checking for email attachment name for containing Javscript code
that could get potentially executed when displayed on a webpage.
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Fri, 8 Mar 2013, John Hardin wrote:
> On Fri, 8 Mar 2013, Sharma, Ashish wrote:
>
>> Here is the requested sample
>>
>> http://pastebin.com/DN7PRnH4
>>
>> The attachment name contains the javascript code at the bottom of the
>> pasted file.
>
> I'll say it again: rather than trying to write SA rules that detect
> javascript in attachment filenames, why not just have the code that generates
> your web pages perform HTML escaping on all user-provided data that will be
> displayed (i.e., the attachment filenames)?
>
> In other words, the page generator would convert that attachment filename
> from "<script>document.write("Hello World");</script>.txt" to
> "<script>document.write("Hello World");</script>.txt"
>
> This is a simple, standard and robust solution to your problem that also
> prevents other attack vectors you haven't thought of yet.
That's fine if the -only- place that crocked message is ever going to be
displayed is on a webserver that you control.
What if it ends up in some client's INBOX and they view it with a "very helpful"
client that processes the javascript, or if the client forwards the message
on to his friend's hotmail/yahoo/gmail/etc address?
I run an AV scanner on our mailserver even though my Linux client isn't
susceptible to viri because stopping crap-ware is the right thing to do.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
RE: Checking for email attachment name for containing Javscript
code that could get potentially executed when displayed on a webpage.
Posted by Benny Pedersen <me...@junc.eu>.
John Hardin skrev den 2013-03-08 20:31:
> This is a simple, standard and robust solution to your problem that
> also prevents other attack vectors you haven't thought of yet.
if php build with tidy its simple :)
RE: Checking for email attachment name for containing Javscript code
that could get potentially executed when displayed on a webpage.
Posted by John Hardin <jh...@impsec.org>.
On Fri, 8 Mar 2013, Sharma, Ashish wrote:
> Here is the requested sample
>
> http://pastebin.com/DN7PRnH4
>
> The attachment name contains the javascript code at the bottom of the pasted file.
I'll say it again: rather than trying to write SA rules that detect
javascript in attachment filenames, why not just have the code that
generates your web pages perform HTML escaping on all user-provided data
that will be displayed (i.e., the attachment filenames)?
In other words, the page generator would convert that attachment filename
from "<script>document.write("Hello World");</script>.txt" to
"<script>document.write("Hello World");</script>.txt"
This is a simple, standard and robust solution to your problem that also
prevents other attack vectors you haven't thought of yet.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Failure to plan ahead on someone else's part does not constitute
an emergency on my part. -- David W. Barts in a.s.r
-----------------------------------------------------------------------
2 days until Daylight Saving Time begins in U.S. - Spring Forward
Re: Checking for email attachment name for containing Javscript code
that could get potentially executed when displayed on a webpage.
Posted by Ned Slider <ne...@unixmail.co.uk>.
On 08/03/13 14:05, Sharma, Ashish wrote:
>>> Can you pastebin an example? Not sure what you mean with the attachment
>>> *name* contains JS code.
>
> Here is the requested sample
>
> http://pastebin.com/DN7PRnH4
>
> The attachment name contains the javascript code at the bottom of the pasted file.
>
> thanks
> Ashish
>
You could try this (untested):
mimeheader L_CT_DOCWRITE Content-Type =~ /document\.write/
score L_CT_DOCWRITE 1
describe L_CT_DOCWRITE Content-type contains document.write
Score as you see fit.
> -----Original Message-----
> From: Axb [mailto:axb.lists@gmail.com]
> Sent: Wednesday, March 06, 2013 3:59 PM
> To: users@spamassassin.apache.org
> Subject: Re: Checking for email attachment name for containing Javscript code that could get potentially executed when displayed on a webpage.
>
> On 03/06/2013 11:20 AM, Sharma, Ashish wrote:
>> All,
>>
>> I have a mail receiving server that parses incoming emails for email attachment and the files are listed on a web page for users to see.
>>
>> Here I need to check for email attachment name for containing Javscript code that could get potentially executed when displayed on a webpage.
>>
>> Is there a way in Spamassassin conf that can help me in testing for the above mentioned scenario?
>
>
> Can you pastebin an example? Not sure what you mean with the attachment
> *name* contains JS code.
>
>
>
>
>
RE: Checking for email attachment name for containing Javscript
code that could get potentially executed when displayed on a webpage.
Posted by "Sharma, Ashish" <as...@hp.com>.
>> Can you pastebin an example? Not sure what you mean with the attachment
>>*name* contains JS code.
Here is the requested sample
http://pastebin.com/DN7PRnH4
The attachment name contains the javascript code at the bottom of the pasted file.
thanks
Ashish
-----Original Message-----
From: Axb [mailto:axb.lists@gmail.com]
Sent: Wednesday, March 06, 2013 3:59 PM
To: users@spamassassin.apache.org
Subject: Re: Checking for email attachment name for containing Javscript code that could get potentially executed when displayed on a webpage.
On 03/06/2013 11:20 AM, Sharma, Ashish wrote:
> All,
>
> I have a mail receiving server that parses incoming emails for email attachment and the files are listed on a web page for users to see.
>
> Here I need to check for email attachment name for containing Javscript code that could get potentially executed when displayed on a webpage.
>
> Is there a way in Spamassassin conf that can help me in testing for the above mentioned scenario?
Can you pastebin an example? Not sure what you mean with the attachment
*name* contains JS code.
Re: Checking for email attachment name for containing Javscript code
that could get potentially executed when displayed on a webpage.
Posted by Axb <ax...@gmail.com>.
On 03/06/2013 11:20 AM, Sharma, Ashish wrote:
> All,
>
> I have a mail receiving server that parses incoming emails for email attachment and the files are listed on a web page for users to see.
>
> Here I need to check for email attachment name for containing Javscript code that could get potentially executed when displayed on a webpage.
>
> Is there a way in Spamassassin conf that can help me in testing for the above mentioned scenario?
Can you pastebin an example? Not sure what you mean with the attachment
*name* contains JS code.
Re: Checking for email attachment name for containing Javscript code
that could get potentially executed when displayed on a webpage.
Posted by John Hardin <jh...@impsec.org>.
On Wed, 6 Mar 2013, Sharma, Ashish wrote:
> I have a mail receiving server that parses incoming emails for email
> attachment and the files are listed on a web page for users to see.
>
> Here I need to check for email attachment name for containing Javscript
> code that could get potentially executed when displayed on a webpage.
Why not just HTML-escape the filenames as a standard practice?
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Failure to plan ahead on someone else's part does not constitute
an emergency on my part. -- David W. Barts in a.s.r
-----------------------------------------------------------------------
4 days until Daylight Saving Time begins in U.S. - Spring Forward