I want to do a "select all" from a table, using an URL. However the URLs stored in my database have funny characters; an URL in my database looks something like this:
http%3A%2F%2Fwww.indeed.co.uk%2Fviewjob%3Fjk%3D62643ba09fe2e936%26qd%3DUl8d87NuQZQD4fDpyxUj6Q3nWG6Z80ksB5Olwd1QWW3wG-YZeyT0yxf8fUYia7g-jLgw8Q9quijZp6li7FQTOh_bZiy_HhLQe1iSKacCzeM%26indpubnum%3D2878078796677777%26atk%3D185867g360mq25sg
How would I select this by using a normal URL string such as "http://www.indeed.co.uk/blablabla", without all the funny %3A%2F characters.
Or is there a way to insert the urls into the database without these characters getting added in. If so how?
If you use PHP, you can use the function urlencode :
$query = "SELECT * FROM table WHERE url = '" . urlencode($urlToSearch) . "'";
Documentation PHP.net
Those are URI encoded characters. It's not clear how those ended up in your database, though it's possible they weren't properly decoded before being saved.
It's sort of possible to decode these in MySQL alone but it's usually better to use a scripting language of some sort to do the conversion for you.
Related
Using MySQLAdmin. Moved data from Windows server and trying to replace case in urls but not finding the matches. Need slashes as I don't want to replace text in anything but the urls (in post table). I think the %20 are the problem somwhow?
UPDATE table_name SET field = replace(field, '/user%20name/', '/User%20Name/')
The actual string is more like:
https://www.example.com/forum/uploads/user%20name/GFCI%20Stds%20Rev%202006%20.pdf
In a case you are using MariaDB you have REGEXP_REPLACE() function.
But best approach is to dump the table into the file. Open it in a Notepad ++
and run regex replace like specified on a pic:
Pattern is: (https:[\/\w\s\.]+uploads/)(\w+)\%20(\w+)((\/.*)+)
Replace with: $1\u$2\%20\u$3$4
Then import the table again
Hope this help
If its MariaDB, you can do the following:
UPDATE table_name SET field = REGEXP_REPLACE(field, '\/user%20name\/', '\/User%20Name\/');
First, please check, what is actually stored in the database: %20 is a html-entity which represents a whitespace. Usually, when you are storing this inside the database, it will be represented as an actual whitespace (converted before you store it) -> Hence your replace doesn't match the actual data.
The second option that might be possible - depending on what you want to do: You are seeing the URL containing %20, therefore you created your database records (which you would like to fetch) with that additional %20 - And when you now try to query your results based on the actual url, the %20 is replaced with an "actual" whitespace (before your query) and hence it doesn't match your stored data.
I am trying to understand a mysql injection not working as expected.
I have a php script that does a login based on username and password supplied on a webpage. The query string looks like this:
$querystr = "SELECT COUNT(*) FROM usertbl WHERE user='$user' and pass='$pass'";
Username and password are escaped before they are used in the querystr above. This means any apastroph(single quote) is escaped as well.
I found a blog describing this very issue here: mysql_escape_string-the-charset-vulnerability.
I tried to replicate what´s explained on that blog, but when I supply hexadecimal characters for user or pass on the website, php somehow doesn´t interpret them as hex it seems.
When I enter for the username on the webpage(password empty):
user\xbf\x27
the query logged by MySQL is:
SELECT COUNT(*) FROM usertbl WHERE user='user\xbf\x27 or 1=1--' and pass=''
So, to me it looks like the hexadecimal characters are not interpreted as such.
For some more debugging, I created the following php script, which I ran on the server:
<?php
header('Content-type: text/plain; charset=gbk');
$hex="\xbf\x27";
echo mysql_escape_string($hex);
?>
The output is:
�\'
Does anybody have an idea why it might not work for me?
Thank you
When you type $hex="\xbf\x27"; in a php script, PHP parses it and stores the string formed by the hexadecimal bytes BF 27.
When you type \xbf\x27 in a web page, it is sent verbatim to the server, so the query ends up with the literal text «\xbf\x27».
The way to exploit it would be to enter that character in the browser (eg. changing your browser encoding to iso-8859-1 and pasting a ¿), or sending a fake HTTP request where you directly insert in the wire any byte you wish. If you are performing the injection through HTTP GET, there's an easy way to insert which is using %-escapes, ie. "&user=user%bf%27%20or%201=1--&pass=".
I am trying to find a string in a MySQL field which is encoded in base64 (for international characters)
Usual search:
$sql = "SELECT * FROM table WHERE field LIKE '%term%' ";
I have tried this:
$sql = "SELECT * FROM table WHERE field name LIKE '%".base64_encode($term)."%' ";
But it does not work all the time, depending on the search term length... For some reason, it gives result whenever my term is an odd-number long...
I have also tried using the MySQL function TO_BASE64() and FROM_BASE64() which did not work...
Can someone please help?
You need to compare the input value against the base64-decoded stored value, so reverse your attempt a little to call FROM_BASE64() on the stored value and compare against the plain input value. You cannot compare a partial match in $term if it is encoded because the partial value will never produce the same or even similar base64 string as the full stored value.
SELECT * FROM `table` WHERE FROM_BASE64(`field`) LIKE '%$term%'
In this context, $term is a plain string, not base64 encoded. It's of course recommended that $term be a bound parameter rather than a plain PHP variable concatenated into the query.
However, this is going to be slow. If you are in any position to change the way your data has been stored, you are highly encouraged to store it in a plain unencoded form. Every query will need to base64-decode every row to find a matching one, which is extremely inefficient.
Note also, that TO_BASE64(),FROM_BASE64() were recently added in MySQL 5.6.1, and therefore may not be available in a lot of installations. You really should change the way the data is stored to eliminate the encoding.
If you don't want to upgrade to MySQL 5.6 or above, you can use the following trick which is removing the padding issue:
SELECT * FROM `table` WHERE
field LIKE '%" . base64_encode($term) . "%'
OR field LIKE '%" . substr(base64_encode($term .'a'),0,-4) . "%'
OR field LIKE '%" . substr(base64_encode($term .'aa'),0,-8) . "%'
OR field LIKE '%" . substr(base64_encode($term .'aaa'),0,-12) . "%'
The search term length issue is therefore avoided. You may optimize this query by using only one of the four LIKE depending on the length of the $term.
I'm developing a Java desktop application that connects with a database, and I would like to know the next. It results that as far as I know, Prepared Statements avoid SQL injections while you don't make a direct concatenation with user data, but today I figured out that it doesn't escape String regex (like '%' from the LIKE operator,) due that it just escapes characters that could break up the String itself and alter the query. So, if user does:
Search = "%Dogs"; // User input
Query = "SELECT * FROM Table WHERE Field LIKE ?";
blah.setString(1, Search);
It will return all the rows that contains 'Dogs' at the beginning by injection.
Now I ask:
1-) Is this something bad / dangerous viewing from a global point?
2-) Is there a full list of Regex that Mysql could use from inside a String? if so, can you please share it with me?
Thank you.
If the user uses such meta characters in their search, the results may or may not be catastrophic, but a search for %% could be bad. A valid search for %Dogs may also not return the results the user was expecting which affects their experience.
LIKE only offers two meta characters, so you can escape them both on your own when acquired from users (simply using something akin to Search = Search.replaceAll("%", "\\\\%")).
I am concerned about inserting text in a MySQl table w.
I have to insert/update text that contains characters such as / " and '
The escape character / could be inserted only if the NO_BACKSLASH_ESCAPES SQL mode is enabled. wich interfere with the characters " and ' see this link http://dev.mysql.com/doc/refman/5.1/en/string-literals.html#character-escape-sequences
If anyone can explain to is in earth the mysql_real_escape_string() I don't came to understated
I would like to find a pure mysql solution
I am not using php. What I am trying to do here is to "simulate " Content Management System: I am about to write a C# coded solution that manage the content in its different forms(article, category ,tag, etc..) and generate .html files, the MySQl database is local in my computer next i will upload the .html files to the server.
I did this to ensure that all my html pages are html valid and because I don't trust any existent solutions (not only when it concerns coding but in life in general)
Please help
each php db connection extension (mysql, mysqli, pdo) has a special way to safe query against sql injections, when you are using mysql extension, it's strongly recommended to use mysql_real_escape_string() function to make safe all variables used in query, it's most widely used function. i think there isn't any pure solution (when you are using mysql extension in php).
from php.net:
mysql_real_escape_string()-Escapes special characters in the
unescaped_string, taking into account the current character set of the
connection so that it is safe to place it in a mysql_query().
Whatever string data can be inserted into SQL query, if formatted according to 2 rules
it is enclosed in quotes (preferably single ones)
it is passed through mysql_real_escape_string()
if both rules followed, there would be not a single problem with whatever characters, either slashes, quotes or anything.
According to your question, / has no special meaning in MySQL. It's \ that is escape character. It can be escaped by another backslash as well.
$str = 'slashes \ quotes \' or whatever " else symbols';
var_dump($str);
$str = mysql_real_escape_string($str);
$sql = "INSERT INTO table SET str='$str'";