[OPT-general] [ outreach-Bugs-800965 ] re opening bug: #795344 sql syntax

[SourceForge.net <no...@so...>]

Bugs item #800965, was opened at 2003-09-05 11:17
Message generated for change (Comment added) made by martinfst
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=410239&aid=800965&group_id=34206

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: OPT 1.X (Max)
>Status: Closed
>Resolution: Fixed
Priority: 1
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guy Davis (guy_davis)
Summary: re opening bug: #795344 sql syntax

Initial Comment:
re opening bug: #795344  
   
I've had a look at version 1.1.0, there is the    
same sql problem (in my opinion).    
    
Summary: necessity for single quoting a value with  
mysql.    
    
example:    
    
SELECT * FROM task WHERE id=$myid    
    
If you get the value from the function "getvalue -    
include/general.php line 162" this function may  
return the    
special value "n/a". So the previous sql:    
    
SELECT * FROM task WHERE id=n/a brings an error.  
 
To correct it you need to single quote all the value 
in all the sql query you do.    
    
Second example (security)    
    
DELECT * FROM task WHERE id=$myid    
    
If the id is provided from a link in the page, it can  
be    
easily forged.. so, something like that can be  
possible:    
    
$myid="1 or id=2 or id=3 or id=4" etc..     
    
DELETE * FROM task WEHRE id=1 or id=2 or id=3 or  
id=4.    
    
If you had single quoted the value, this wouldn't    
function.    
    
Conclusion: this bug is not to be found on this place  
or    
another, you need to correct all the sql queries and  
add a    
single quote. Even if actualy you don't seems to see  
this    
error, it's a potential error that could arise  
later..     
    
Best regards    
    
ps: sorry for my english, I hope you could understand  
my    
point of view.    
    
Yann Sagon    
y dot sagon at hasa dot ch    

----------------------------------------------------------------------

>Comment By: Martin Vernooij (martinfst)
Date: 2006-09-10 15:52

Message:
Logged In: YES 
user_id=608879

With the 1.2.7 Max release, a lot of SQL statements and
associated functions have been revisited. As this bug is no
longer reproducable, I thinks this has been fixed.

Martin

----------------------------------------------------------------------

Comment By: Ronny Hanssen (godvin)
Date: 2003-11-06 11:27

Message:
Logged In: YES 
user_id=347330

I have also had this problem. It has happened maybe 4 or 5 
times I think. It specifically referred to the n/a value.

I would seriously reconsider the priority of this bug, since it 
does annoy the users quite bad. Also it makes the users loose 
their trust in OPT, since it "evidently is so buggy"...



----------------------------------------------------------------------

Comment By: Guy Davis (guy_davis)
Date: 2003-10-06 01:15

Message:
Logged In: YES 
user_id=22084

Ok.  I understand what your first message was trying to get
at now.  However, MySQL actually doesn't recommend that web
applications use quoting to catch malformed user input. 
They indicate this should be handled by the application not
the database.  In the case of task deletion, you can see
that the user input variable is first run through abs()
which would throw a parse exception on something other than
a valid number.  This isn't the prettiest way to handle the
error, but it doesn't rely on the database to handle it and
it doesn't allow for SQL injection.  

However, I understand your general concern.  I'll leave this
issue open at low priority and hopefully get to it one day.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=410239&aid=800965&group_id=34206