> One thing that was not mentioned (albeit it is solved by the parsing section
> of the solution) is sql injection. Not sure if this is of use - I'd
> consider it as "one-dimensional" as the SSI scenario so I thought I'd
> suggest it.
>

I haven't gotten the SSI method to work on a largescale commerical app yet.
I have found a few custom sites affected by this bug. html and script insertion
has been found on 1 application so far and another smaller german application.
If its possible and has been done once it can be done again.

I forgot to think about any database injection good point. This is a basic
paper "I'm Sure this paper doesn't cover EVERY use for this attack," to mention
a overlooked point.

This could be considered an addition to cross site scripting as mentioned
in a email I got which is true, althoug the delivery method is much different.

Whenever I publish this offically on my site I'll throw in a vendor or two
affected. Currently patches are being made.

>
> For any comprehensive tracking / statistics purposes you will quickly find
> yourself using a database - mostly as it will scale much better under load,
> but also because it allows fast real-time analysis for all the data gathered
> (which adds $$$ as a selling point of a package I'd imagine).
>
> Why does this present a problem?
>
> If the most efficient route to get that data stored is to directly input it
> into the database that is the route you would expect the component to take -
> it introduces the minimum delay in the storage process and therefore gives
> faster performance.
>i

Most of these products check apache logs directly. So if you can modify the
information in the logs, you can modify the output. Its all user input
weither the user knows it or not.

 
> Now assuming the procedure it used to store the data did not modify the
> headers at all, it would be trivial to modify those headers to insert your
> own sql commands - at this point whatever level of database access the
> component has, the attacker now has.
>i

Agreed.
The possibility of such DB injection is limited on the otherhand. Then again
if its possible mention it. I'll throw that tidbit in the paper anyhow.

 
> As a minimum it would allow them to stop their own actions appearing here
> (since deformed inserts will not commit) as well as making their own inserts
> (since the component needed to in order to store data), if there were weak
> permissions (or no permissions( the possibilities are endless.
>
> Regards - Tony
>i

Thanks for a good response and feedback..

- zeno

 
> - -----Original Message-----
> From: zeno [mailto:bugtraqcgisecurity.net]
> Sent: 16 January 2002 16:06
> To: webappsecsecurityfocus.com
> Subject: Header paper/Web Stats software
>
>
> Hello,
>
> I have a question. I'm writing a paper on header manipulation on web
> statistics
> software involving injection of html, ssi, javascript, vbscript,etc.. I've
> managed
> to find examples of all of the above. I have not found any php examples
> though. I'm
> not a php coder so I have a few questions.
>
>
> First read this UNFINISHED PAPER/UNEDITED.
> http://www.cgisecurity.net/papers/header-based-exploitation.txt
> (Probably riddled with errors so don't flame me horribly)
>
>
>
> Then is it possible to insert php commands? I wrote in the paper it was
> based
> off of theory but theory doesn't always cut the cheese. This isn't going
> to be published until I correct the errors. Also would tcl,python, xml,
> other
> have this same issue?
>
> Thanks
>
> - - zenomorph
>
> PS: be nice :)
>
> .
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
> Comment: http://evolvedcode.net/
>
> iQA/AwUBPEcwlq0tBy4nR959EQJysACfW7hyl+I0LPeye0Ce0GvS00UjTowAoPJ2
> QmmSLBt58ZHxZBjD+lAdWHMG
> =PWSs
> -----END PGP SIGNATURE-----
>
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]