Security implications of using open() on untrusted strings.
grahn+nntp at snipabacken.se
Tue Nov 25 23:12:28 CET 2008
On Tue, 25 Nov 2008 02:26:32 -0500, r0g <aioe.org at technicalbloke.com> wrote:
> Jorgen Grahn wrote:
>> Or am I missing something?
> No Jorgen, that's exactly what I needed to know i.e. that sending
> unfiltered text to open() is not negligent or likely to allow any
> badness to occur.
> As far as what I was looking for: I was not looking for anything in
> particular as I couldn't think of any specific cases where this could be
> a problem however... my background is websites (where input sanitization
> is rule number one) and some of the web exploits I've learned to
> mitigate over the years aren't ones I would have necessarily figured out
> for myself i.e. CSRF
I have no idea what CSRF is, but I know what you mean. And it applies
in the safe and cozy Unix account world too -- that the exploits are
surprising, I mean. Maybe I made it out to be *too* safe in my
previous posting. But still ...
> So I thought I'd ask you guys in case there's
> anything I haven't considered that I should consider! Thankfully it
> seems I don't have too much to worry about :-)
... no, in this case you're just doing what everybody else does,
and you have no alternative plan (filter for what?)
There ought to be some list "common attacks on applications run by
local Unix users" which one could learn from. Maybe it's not obvious
that the content of a local file should, in many situations, be
handled as untrusted. In the meantime, there's things like this:
Many of them are local exploits.
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!
More information about the Python-list