Re: Spam attack, observations, how to repair

Hello Ralf,

2014-07-04 15:48 GMT+02:00 Ralf Schlatterbeck <[email protected]>:

> On Fri, Jul 04, 2014 at 02:18:22PM +0200, Ralf Schlatterbeck wrote:
> > This is the hint. Roundup only rewrites the content-type "text/html" not
> > just "html" but it seems the browser wants to be helpful and renders
> > this as html -- which it shouldn't. I'll fix this so that in this case
> > we will indicate a content-type of application/octet-stream which the
> > browser should not render.
>
> I've verified this is indeed the case. Content type 'html' or 'HTML' is
> rendered as html (my test-browser was the debian version of firefox aka
> iceweasel). I've just committed a fix that now checks if 'html' is
> contained in the content-type (case insensitive) and ships this as
> application/octet-stream unless allow_html_file is explicitly specified
> in the configuration.
>

So, should I create a trac ticket for this. I certainly would like to alert
Debian to this issue. I consider it security relevant, not sure if that is
by the definition though. For that an upstream issue will be best.

It's also relevant that search engines believe it is HTML and that it is
indexing links. Even browsers were not to render, that would still be
sufficient to steal our site rankings for spam links.

The trailing slash definitely made a difference to the browser. I have
seen the other discussion of why it is potentially useful, but I would
want to see ambiguity removed. The browser seeing "/something"
or "/something/" makes apparently more likely for the later to apply
guesswork.

Also please let me know once it is pip installable. For now I am going
to apply the script of yours to make the cleanups, but I am going to
be vulnerable still.

As to human, I found it noteworthy that in at least one case, the attacker
has copied my main site layout, and replaced the body content. That
was a 404 only, because I changed it later, and reported to me as I am
the owner of that link target as well.

BTW: Content type changes is probably something that I would like to
not allow I guess. And certainly not to random strings:


kayhayensettype: html -> html2
This is also something that enabled the attack in the first place. With
the users being allowed to set non-Mime types, we allow an attacker
to force the wholeBrowser / Search engine guessing.

And while there, I think, with "allow_html_file = no", the following
ought to be prevented:


kayhayensettype: html2 -> text/html
Yours,
Kay

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft

_______________________________________________
Roundup-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/roundup-users