Monday, 30-Nov-15 20:50:00 CET

Porting my blog for the second time, right sidebar part 1

This is post #36 of my series about how I port this blog from Blogengine.NET 2.5 ASPX on a Windows Server 2003 to a Linux Ubuntu server, Apache2, MySQL and PHP. A so called LAMP. The introduction to this project can be found in this blog post /post/Porting-my-blog-for-the-second-time-Project-can-start.

Now it is time for the right sidebar of my blog. The right sidebar is more narrow than the left and it is the first to move to the bottom in case the window gets narrower. For this sidebar I decided to put a short summary of myself.

I could create a general kind of storage for texts to be used in the blog but I decided to write the bio in the PHP file directly. By doing so I avoid much of the extra effort necessary to administrate various texts via the database. This is what I will do for now. Later on I will come back to some kind of general storage of texts.

Next on my right sidebar is a search field. So up until now I created security by stripping down any possible input into the page to very secure and valid identification codes. Now on the other hand with a search field we open up for nasty stuff. So how about security? Found an interesting article by Josh Duff.

http://joshduff.com/#!/post/2011-05-10-why-you-should-not-be-using-mysqli-prepare.md

Currently I am using mysqli and for now I will stay on that. Probably very soon I will start experiment with PDO as well but for now it is mysqli. Some sources claims that both mysqli and PDO are vulnerable for SQL injection attacks especially if one is using other character sets than utf8. Well I use utf8 both in the page, php and in the database.

In the link here above Josh Duff made his own prepare routine. It used of mysql_escape_string that since then has been depreciated. The main unique selling point of that depreciated routine was that it knew what character set the database was set to so that I could safely convert characters but I already know that.

There are more characters and strings that I don't want to get through to the database than most prepare routines takes care of. Many many more. Could it be so that the reason is that the regular prepare is made in such way that you can actually do things in the database but I don't need that, I just want to search. I really don't want to sound arrogant that I roll my own mysql_escape_string but really, is it arrogant? My search really don't need update/create/drop tables or select from tables. It just needs to get enough characters through to search for blog entries and the rest it needs to filter. Here are the characters I don't  want:

After these replacements I run the result through quoted_printable_encode. Am I safe? Hmm... There are others in Internet that very thoroughly explains that the only secure method is to use prepared statements. And that security is more important than that each query takes 3 round trips to the database instead of one trip to the database.

http://www.programmerinterview.com/index.php/database-sql/sql-injection-prevention

Well I don't get prepared statements to work with mysqli so I guess I am rolling on my own until I get the hang of PDO. But not tonight.

Even then... When I get PDO to work I will probably roll my own security layer on top of it. Hehe... No I am not arrogant.

So alright suppose I got my security in place. Then what? Actually get the form set up and have it send its data to the php page and produce a query (safely) and then present the result in a result table. But that is for the next time.