PHP curly braces in database value - php

so I have an issue. We have some values in our DB stored like the following:
{yoyoyo}
This is great until we pull the value out of the DB using PHP. It appears to break PHP when trying to access the variable like so:
$result['curly'];
For some reason PHP is interpreting that as if its a variable.
Anyone know how to escape the result from the DB so PHP interprets it as a string and not a variable?
Thanks!

You could use htmlentities - http://php.net/manual/en/function.htmlentities.php
This will convert all characters to html entities. You can also in the future store things that don't need to be used as variables to html entities before putting them in the database to avoid this problem.
http://www.freeformatter.com/html-entities.html

Yeah, after further research it appears that it's pulling the string value out of the DB just fine. However, later on in our code we were doing other, lets just say, inefficient stuff. :)

Related

When to use: htmlspecialchars? [duplicate]

This question already has answers here:
when to use htmlspecialchars() function?
(4 answers)
Closed 9 years ago.
I need to convert my strings to special characters using:
htmlspecialchars
My question is, should I convert my data before submitting it to a database or should I convert it before I display it?
You should sanitize data before inserting it into a database, and escape it on retrieval.
htmlspecialchars is used for escaping, so it should be after you’ve fetched it from the database.
It makes the data safe to insert into an HTML document. Use it before you insert it into an HTML document, not a database.
It's generally the better idea to not modify source data before storing it. It will tie your data to the specific context you're using it in. What if you ever need a different way of displaying it, e.g. in a PDF, or text format? Then you will have the html entities in your text and would need to convert them back.
IMHO Performance considerations are secondary in this regards, one can still make use of caching technologies for views for this.
So, on the bottom line I suggest you always prepare your strings before display.
I'm assuming the data is already escaped sanitised before you put it into the database so it is safe. From there, I try to change the data as little as possible on the way to the database.
The thing to remember is that maybe you're using the copy now on your website, but later down the line you may like to use it on a different device or on print. If you use htmlspecialchars before it goes to the database, you'll have to clean it up if you want to use it for something other than HTML. Formatting dates as strings before putting them into a database is a common one, but when you want to change the format...

Store special character in mysql database that can be read by JavaScript and HTML

I'm storing data in a MySQL database that may have some special characters. I'm wondering how to store it so that these characters are preserved if they're either output to HTML via PHP OR via JavaScript, e.g. createTextNode.
For example, the division symbol (÷) has the html code ÷, and when I store it as that it shows up fine when put directly into HTML by PHP, but when I pull it into JavaScript using $.getJSON and then insert it with createTextNode it shows up looking like ÷.
I also tried storing the symbol in the SQL directly, but my understanding is that the column would need to be changed from VARCHAR to NVARCHAR and that would cause a performance hit that doesn't seem necessary.
Given that I can modify the SQL, the PHP, or the JavaScript, is there an easy fix here? Maybe a way to unescape the HTML entity in JavaScript?
As answered by Yogesh, you should switch your collation of the DB to utf8_general_ci
So there's probably two things going on:
JSON escapes special characters.
Somewhere, something in your code flow is URL encoding the strings too.
So you just need to decode the string in your JavaScript, or you need to find what part of your code is URL encoding those strings and fix it.

How to prevent ) from being inserted in a Database in PHP?

I am working on a PHP/MySQL script that is inserting data into a database like this...
Caesar (courtesy post)
I know this is a basic question but how can I prevent the special characters from doing that?
It seems you're not just HTML-escaping your content once, but actually doing it twice. The first thing you should do is try to find out why your content ends up that way, instead of attempting to decode it to an unescaped format. You should always escape for the format you're going to use the data in, escape with the SQL escape functions when inserting, and escape with htmlspecialchars (or a similar function) when presenting the data in HTML (and take note of the character encoding used).
If the data comes in this format from another source, use html_entity_decode to normalize the text again. That does however seem weird.

Sanitizing PHP/SQL $_POST, $_GET, etc...?

Ok, this subject is a hotbed I understand that. I also understand that this situation is dependent on what you are using as code. I have three situations that need to be resolved.
I have a form in where we need to allow people to make comments and statements that use commas, tildes, etc... but still remain safe from attacks.
I have people entering in dates like this: 10/13/11 mm/dd/yy in English, can this be sanitized?
How do I understand how to use htmlspecialchars(), htmlentities() and real_escape_string() correctly? I've read the php.net site and some posts here but this seems to me to be a situation in where it all depends on the person reading the question what the right answer is.
I really can't accept that... there has to be an answer wherein text formats similar to that which I am posting here can be sanitized. I'd like to know if and how it is possible.
Thanks... because it seems to me that when asking this question in other places it tends to annoy... I am learning what I need to know but I think I have hit a plateau in what I can know without an example of what it is meant to do...
Thanks in advance.
It's a very important question and it actually has a simple answer in the form of encodings. The problem you are facing it that you use a lot of languages at the same time. First you are in HTML, then in PHP and a few seconds later in SQL. All these languages have their own syntax rules.
The thing to remember is: a string should at all times be in its proper encoding.
Lets take an example. You have a HTML form and the user enters the following string into it:
I really <3 dogs & cats ;')
Upon pressing the submit button, this string is being send to your PHP script. Lets assume this is done through GET. It gets appended to the URL, which has its own syntax (the & character has special meaning for instance) so we are changing languages. This means the string must be transformed into the proper URL-encoding. In this case the browser does it, but PHP also has an urlencode function for that.
In the PHP script, the string is stored in $_GET, encoded as a PHP string. As long as you are coding PHP, this is perfectly fine. But now lets put the string to use in a SQL query. We change languages and syntax rules, therefore the string must be encoded as SQL through the mysql_real_escape_string function.
At the other end, we might want to display the string back to the users again. We retrieve the string from the database and it is returned to us as a PHP string. When we want to embed it in HTML for output, we're changing languages again so we must encode our string to HTML through the htmlspecialchars function.
Throughout the way, the string has always been in the proper encoding, which means any character the user can come up with will be dealt with accordingly. Everything should be running smooth and safe.
A thing to avoid (sometimes this is even recommended by the ignorant) is prematurely encoding your string. For instance, you could apply htmlspecialchars to the string before putting it in the database. This way, when you retrieve the string later from the database you can stick it in the HTML no problem. Sound great? Yeah, really great until you start getting support tickets of people wondering why their PDF receipts are full of & > junk.
In code:
form.html:
<form action="post.php" method="get">
<textarea name="comment">
I really <3 dogs & cats ;')
</textarea>
<input type="submit"/>
</form>
URL it generates:
http://www.example.org/form.php?comment=I%20really%20%3C3%20dogs%20&%20cats%20;')
post.php:
// Connect to database, etc....
// Place the new comment in the database
$comment = $_GET['comment']; // Comment is encoded as PHP string
// Using $comment in a SQL query, need to encode the string to SQL first!
$query = "INSERT INTO posts SET comment='". mysql_real_escape_string($comment) ."'";
mysql_query($query);
// Get list of comments from the database
$query = "SELECT comment FROM posts";
print '<html><body><h2>Posts</h2>';
print '<table>';
while($post = mysql_fetch_assoc($query)) {
// Going from PHP string to HTML, need to encode!
print '<tr><td>'. htmlspecialchars($post['comment']) .'</td></tr>';
}
print '</table>';
print '</body></html>'
The crucial thing is to understand what each sanitising function available to you is for, and when it should be used. For example, database-escaping functions are designed to make data safe to insert into the database, and should be used as such; but HTML-escaping functions are designed to neutralise malicious HTML code (like JavaScripts) and make it safe to output data for your users to view. Sanitise the right thing at the right time.*
There are two different basic approaches you can take: you can sanitise HTML when you receive it, or you can store it exactly as you received it and sanitise it only when it is time to output it to the user. Each of these methods has its proponents, but the second one is probably the least prone to problems (with the first one, what do you do if a flaw is discovered in your sanitising procedure and you find you have insufficiently sanitised content stored in your database?)
Dates can be sanitised using a date parsing function. In PHP you might look at strtotime(). Your objective is typically to take a string representation of a date and output either an object representing a date, or another string that represents the same date in a canonical way (that is: in a specific format).
Regarding the sanitization of dates, PHP has some built-in functions that can be helpful. The strtotime() function will convert just about any imaginable date/time format into a Unix timestamp, which can then be passed to the date() function to convert it to whatever formatting you like.
For example:
$date_sql = date( "Y-m-d", strtotime( $_POST["date"] ) );

What's the best practice method for storing raw php, javascript, html or similar in a mysql database?

The example web page has 2 fields and allows a user to enter a title and code. Both fields would later be embed and displayed in an HTML page for viewing and/or editing but not execution. In other words, any PHP or javascript or similar should not run but be displayed for editing and copying.
In this case, what is the best way to escape these fields before database insertion and after (for HTML display)
You need to use the function htmlspecialchars() in php
that will change any special characters (eg < and >) into their special HTML encoded characters (eg &lt and &gt). When you get these from the database and output them as HTML they will display as code, but won't harm your script or execute.
I faced with the same problem a few days back, to put the codes (javascript or PHP ) in the html in a non executable way, I used textarea, it solved the purpose.
The problem however, was with the database. I cannot use the typical escape functions with the data, as it is affecting my data, for example the tags are getting messed up.
To solve this problem, I encoded the data in base 64 format before putting it in the database. So what is happening is my JavaScript code is encoded and the resultant code is no longer a Javascript code and I can use the escape functions on this and store it in the database.
I am open to suggestions, feel free to comment.

Categories