I have found in my Script this 2 Problems, SQL Injection and Cross-Site Scripting.
SQL Injection:
$cate = mysqli_real_escape_string($connection, #$_REQUEST['cat']);
$categ = mysqli_query($connection, "SELECT * FROM articles WHERE category='$cate'");
Where the category='$cate' is the Problem.
XSS:
echo''.$catego.'';
But i dont understand why is $cate wrong?
Anyone an Example for the Correct solution?
Thanks all
Your problem is that you take a value from a request directly to a SQL query.
The best way to prevent SQL injection is to use prepared statements. Prepared statements solve the SQL Injection problem. You must
Validate the $_REQUEST['cat'] value
Use (for example) PDO to prepare the statement (http://php.net/manual/en//pdo.prepared-statements.php)
Read : https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
In Legacy sql, we can do SELECT ABS(HASH('12345')) to get unique hash number of a value.
I am in process of converting legacy sql to standard sql in GBQ,
so wondering whats the best way to convert above function so that it gives me same value back as legacy sql.
We won't expose a function that returns the same values as in legacy SQL; it uses an undocumented implementation. The closest equivalent when using standard SQL is FARM_FINGERPRINT, which uses the open-source FarmHash library.
For the expression that you provided, you would instead use ABS(FARM_FINGERPRINT('12345')).
I just saw this come up in our request logs. What were they trying to achieve?
The full request string is:
properties?page=2side1111111111111 UNION SELECT CHAR(45,120,49,45,81,45),CHAR(45,120,50,45,81,45),CHAR(45,120,51,45,81,45),CHAR(45,120,52,45,81,45),CHAR(45,120,53,45,81,45),CHAR(45,120,54,45,81,45),CHAR(45,120,55,45,81,45),CHAR(45,120,56,45,81,45),CHAR(45,120,57,45,81,45),CHAR(45,120,49,48,45,81,45),CHAR(45,120,49,49,45,81,45),CHAR(45,120,49,50,45,81,45),CHAR(45,120,49,51,45,81,45),CHAR(45,120,49,52,45,81,45),CHAR(45,120,49,53,45,81,45),CHAR(45,120,49,54,45,81,45) -- /*
Edit: As a google search didn't return anything useful I wanted to ask the question for people who encounter the same thing.
This is just a test for injection. If an attacker can see xQs in the output then they'll know injection is possible.
There is no "risk" from this particular query.
A developer should pay no attention to whatever injection mechanisms, formats or meanings - these are none of his business.
There is only one cause for for all the infinite number of injections - an improperly formatted query. As long as your queries are properly formatted then SQL injections are not possible. Focus on your queries rather than methods of SQL injection.
The Char() function interprets each value as an integer and returns a string based on given the characters by the code values of those integers. With Char(), NULL values are skipped. The function is used within Microsoft SQL Server, Sybase, and MySQL, while CHR() is used by RDBMSs.
SQL's Char() function comes in handy when (for example) addslashes() for PHP is used as a precautionary measure within the SQL query. Using Char() removes the need of quotation marks within the injected query.
An example of some PHP code vulnerable to an SQL injection using Char() would look similar to the following:
$uname = addslashes( $_GET['id'] );
$query = 'SELECT username FROM users WHERE id = ' . $id;
While addslashes() has been used, the script fails properly sanitize the input as there is no trailing quotation mark. This could be exploited using the following SQL injection string to load the /etc/passwd file:
Source: http://hakipedia.com/index.php/SQL_Injection#Char.28.29
In my iPhone app I am using an Sqlite database. I have a requirement to store the text in database. The text contains apostrophes.
For example:
Insert into tbl_insert values ('It is Steve's Shirt');
How to store this kind of statements in Sqlite database?
This is something that I go through in SQL Server and MySQL as well. You should definitely use parameterised SQL queries
See this page for examples in many languages.
I strongly discourage the use of literal strings in the update statement. Use parameterized queries. There's no reason to compromise security
You can write a function which replaces each instance of character ' with ''
http://www.kamath.com/codelibrary/cl003_apostrophe.asp
Simply replace ' characters to ` :)
text = text.replace("'", "`");
With python and sqlite3 i found that the following line worked perfectly (replacing ' with '')
myString = myString.replace('\'', '\'\'')
the string can then be concatenated in an UPDATE command
The line is stored and displayed correctly. It also works great with Grafana.
I'm not yet sure if this is specific to the sqlite3 python module or if it can be generalized
NOTE: It's probably a duplicate but I can't find working answer.
Following is what i'm trying todo, notice a ' in the value. How do I fix this?
INSERT INTO [pugraider].[dbo].[Realms]([Name]) VALUES('Aman'Thul')
I use MS SQL Server Management Studio 2008.
EDIT: I'm writing a script to populate a lookup table (ID<->Name).
This will work:-
INSERT INTO [pugraider].[dbo].[Realms]([Name]) VALUES('Aman''Thul')
Ordinarily the only reason to have such hardcoded values in T-SQL is in DB construction code such as initialising look up tables.
Otherwise this code might be a result of string concatenation to build up some T-SQL from some input source. If that is the case its worth finding ways to avoid it since it can open your application to SQL injection attacks.