Updating a filename's counter value failed each time

[MRAB]

On 17/06/2013 19:32, Jens Thoms Toerring wrote:
> Νίκος <support at superhost.gr> wrote:
>> On 17/6/2013 8:54 μμ, Jens Thoms Toerring wrote:
>> > Also take care to check the filename you insert - a malicous
>> > user might cobble together a file name that is actually a SQL
>> > statement and then do nasty things to your database. I.e. never
>> > insert values you received from a user without checking them.
>
>> Yes in generally user iput validation is needed always, but here here
>> the filename being selected is from an html table list of filenames.
>
>> But i take it you eman that someone might tried it to pass a bogus
>> "filename" value from the url like:
>
>> http://superhost.gr/cgi-bin/files.py?filename="Select....."
>
>> Si that what you mean?
>
> Well, you neer wrote where this filename is coming from.
> so all I could assume was that the user can enter a more
> or less random file name. If he only can select one from
> a list you put together there's probably less of a problem.
>
>> But the comma inside the execute statement doesn't protect me from such
>> actions opposed when i was using a substitute operator?
>
>> > I would guess because you forgot the uotes around string
>> > values in your SQL statement which thus wasn't executed.
>
>> i tried you suggestions:
>
>> cur.execute('''UPDATE files SET hits = hits + 1, host = %s, lastvisit =
>> %s WHERE url = "%s"''', (host, lastvisit, filename) )
>
>> seems the same as:
>
>> cur.execute('''UPDATE files SET hits = hits + 1, host = %s, lastvisit =
>> %s WHERE url = %s''', (host, lastvisit, filename) )
>
>> since everything is tripled quoted already what would the difference be
>> in "%s" opposed to plain %s ?
>
> As I wrote you need *single* quotes around strings in
> SQL statements. Double quotes won't do - this is SQL
> and not Python so you're dealing with a different lan-
> guage and thus different rules apply. The triple single
> quotes are seen by Python, but SQL needs its own.
>
The query looks safe to me as he _is_ using a parametrised query.