I was curious if it's possible to protect against an SQL injection attack by removing all spaces from an String input?
I have been reading up on SQL Injection at OWASP, but they don't mention anything about removing spaces, so I was curious why it would, or would not work?

I was looking at this question, which asks about trim, and the top answer says this:

No, adding a trim will not prevent sql injection. trim only removes space on the outside of your string.
Select * from aTable where name like '%'+@SearchString+'%'

If you @SearchString held something like
'' update aTable set someColumn='JackedUpValue' where someColumn like '

Then when you put it all together and execute it dynamically you would get
Select * from aTable where name like '%' update aTable set someColumn='JackedUpValue' where someColumn like '%'



However if you took that search string
update aTable set someColumn='JackedUpValue' where someColumn like 

and performed the operation shown in this question, wouldn't you get
updateaTablesetsomeColumn='JackedUpValue'wheresomeColumnlike

which should not execute, right?
I'm curious if there is any form of SQL injection that could defeat this?  Are there one word dangerous commands? If this can be defeated, would removing spaces at least help a bit with defense?
Note: I'm asking this question purely out of curiosity, not as way to circumvent using the "proper" methods of SQL Injection Prevention.

No. Removing spaces would not prevent SQL injection, as there are many other ways to make the parser process your input. Lets look at an example. Imagine that you had a url which used user supplied input unsafely in a query:

http://example/index.php?id=1 => SELECT * from page where id = 1

In your example the attacker would use spaces:

http://example/index.php?id=1%20or%201=1 => SELECT * from page where id = 1 or 1=1. 

Removing the spaces would collapse the injection into a string.

Now let's imagine that the attacker used another form of white space, i.e. tabs:

http://example/index.php?id=1%09or%091=1 => SELECT * from page where id = 1     or    1=1. 

Removing the spaces would still allow the injection through.

Depending on the technology in use the attacker could replace the spaces with /**/ %00 %09 %0a %0d or any number of unicodes that causes tokenization by the SQL parser. While the referenced example removed more than just spaces, the aforementioned example takes advantage of SQL comments to cause the tokenization which are not whitespace. You would still be vulnerable.

The only reliable way to prevent SQL injection is to use parameterized queries.
