Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Code vulnerable for SQL injections #28

Open
YOUR1 opened this issue Feb 16, 2022 · 4 comments
Open

Code vulnerable for SQL injections #28

YOUR1 opened this issue Feb 16, 2022 · 4 comments

Comments

@YOUR1
Copy link

YOUR1 commented Feb 16, 2022

Hi,

I see a lot of lines like this function:

	public function getBatch ( $id ) {
		$id *= 1 ;
		$ret = array('commands'=>array()) ;
		$db = $this->getDB() ;
		$sql = "SELECT * FROM command WHERE batch_id=$id" ;
		if(!$result = $db->query($sql)) return $this->setErrorMessage ( 'There was an error running the query [' . $db->error . ']'."\n$sql" ) ;
		while ( $o = $result->fetch_object() ) {
			$j = json_decode ( $o->json ) ;
			$j->_meta = $o ;
			unset ( $j->_meta->json ) ;
			$ret['commands'][$o->num] = $j ;
		}
		return $ret ;
	}

If one would simply set $id to 0;DROP TABLE COMMAND;, the command table will be gone. Easy as that.. Please, for the love of god; use SQL prepared statements. See: https://www.w3schools.com/php/php_mysql_prepared_statements.asp

@lucaswerkmeister
Copy link
Contributor

The $id *= 1 at the start of the method effectively casts it to a number or throws an exception, so by the time of the $sql assignment it should be safe. I know the code looks scary, but IIRC I looked through it at some point and didn’t find any remaining places that were actually vulnerable.

@lucaswerkmeister
Copy link
Contributor

(Correction by @GreenReaper: throwing an exception is new in PHP 8, in PHP 7 it raises a warning and evaluates to 0, or maybe it depends on some kind of strictness setting too. But at no point does the string survive into the $sql, I believe.)

@GreenReaper
Copy link

GreenReaper commented Feb 16, 2022

Could avoid the exception with type coercion to int if that is desired. As it is, it'd probably still take a float, which may not be desirable to present to SQL that expects an int (I don't think you can pass in INF or NAN; they'd be taken as strings, not constants).

In the general case, yes, it's probably a good idea to use parameterized queries in new code and seek to convert old ones, because it's easy to slip up.

@YOUR1
Copy link
Author

YOUR1 commented Feb 17, 2022

The $id *= 1 at the start of the method effectively casts it to a number or throws an exception, so by the time of the $sql assignment it should be safe. I know the code looks scary, but IIRC I looked through it at some point and didn’t find any remaining places that were actually vulnerable.

Maybe in this particular example.. But that's not the point. Not using prepared statements is not something you would like to do..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants