Bug 7857 - <a data-saferedirecturl="">
Summary: <a data-saferedirecturl="">
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Libraries (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: All All
: P2 blocker
Target Milestone: 4.0.0
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-09-21 07:16 UTC by AXB
Modified: 2020-09-21 19:56 UTC (History)
2 users (show)


Attachment Type Modified Status Actions Submitter/CLA Status
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description AXB 2020-09-21 07:16:48 UTC 
Please consider making SA aware of the data-saferedirecturl html tag for URI lookups.
This is "hiding" phish,generic spam are a google redirect-


Sample of such case will follow
Comment 1 AXB 2020-09-21 07:24:16 UTC 
sample URI:

<a href="https://example.com/very/legit/url" target="_blank" rel="noreferrer" data-saferedirecturl="https://www.google.com/url?q=https://example.org/very/evil/url&amp;source=gmail&amp;ust=123456789/*&amp;usg=laksjdflasi">Update user@example.com now</a>
Comment 2 Kevin A. McGrail 2020-09-21 16:41:21 UTC 
Good catch, AXB.
Comment 3 John Hardin 2020-09-21 17:33:15 UTC 
underway
Comment 4 John Hardin 2020-09-21 18:00:05 UTC 
Modified: trunk/lib/Mail/SpamAssassin/HTML.pm
Added: trunk/t/uri_saferedirect.t
Committed revision 1881911.
Comment 5 John Hardin 2020-09-21 18:00:56 UTC 
Do we want to backport this to 3.4?
Comment 6 AXB 2020-09-21 18:03:09 UTC 
(In reply to John Hardin from comment #5)
> Do we want to backport this to 3.4?

if you can, that would be great,
Comment 7 John Hardin 2020-09-21 18:44:05 UTC 
Modified: branches/3.4
Modified: branches/3.4/lib/Mail/SpamAssassin/HTML.pm
Added: branches/3.4/t/uri_saferedirect.t
Committed revision 1881912.
Comment 8 Kevin A. McGrail 2020-09-21 18:56:00 UTC 
Thanks for the backport.  How safe do you feel the change is?
Comment 9 Kevin A. McGrail 2020-09-21 18:56:55 UTC 
Nevermind, I see it now.  A test and a 3 line patch +1 for 3.4
Comment 10 John Hardin 2020-09-21 19:56:38 UTC 
I just noticed an apparent error in the antipatterns in the test script that I cloned:

185 	invalid_ltd.foo         !invalid_tld
186 	invalid_ltd.bar         !invalid_tld
187 	invalid_ltd.xyzzy       !invalid_tld
188 	invalid_ltd.co.zz       !invalid_tld
189 	
190 	www.invalid_ltd.foo     !invalid_tld
191 	www.invalid_ltd.bar     !invalid_tld
192 	www.invalid_ltd.xyzzy   !invalid_tld
193 	www.invalid_ltd.co.zz   !invalid_tld

Shouldn't the "_ltd" / "_tld" bit match to ensure the invalid TLD is not captured as a URI?

Or are these essentially NOP'd out by mangling because SA is not doing valid-TLD filtering? If so, should these be explicitly commented out instead of being mangled so they pass? Like this antipattern:

222 	#keyword:sportscar              !sportscar

The SVN history shows it's been that way since the initial commit.