I am busy building a custom CMS with a lot of features which include API's (so accessing other websites).
For safety measures I protected all Mysql inputs with mysql_real_escape_string, strip_tags and htmlspecialchars.
For my login system I used two things:
Sessions will hold user name + logged (true or false).
And at the beginning of every page that is restricted i used the following code to check if a user is logged in.

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

2

You should first replace all your mysql_* functions. As of PHP 5.5.0 they are deprecated. Use something like PDO or MySQLi
–
0DEFACEDDec 19 '12 at 18:53

From the documentation for mysql_real_escape_string: This extension is deprecated as of PHP 5.5.0, and will be removed in the future. Instead, the MySQLi or PDO_MySQL extension should be used. See also MySQL: choosing an API guide and related FAQ for more information. Alternatives to this function include: The first step to making your code secure is to pay attention to the bright red signs telling you that it's not.
–
Brendan LongDec 19 '12 at 18:55

If you aren't sure about your security practices, do everyone a favor and don't make a new CMS. We are all full up on insecure CMSs.
–
DampeS8NDec 19 '12 at 18:57

This is a pretty good explanation of how to avoid SQL injection attacks with no effort: codinghorror.com/blog/2005/04/… The sad thing is that it's so easy but when people get into PHP, someone inevitably tells them the wrong way to do things.
–
Brendan LongDec 19 '12 at 18:58

@DampeS8N Learning how to build one and publishing it for general use are not the same thing. After building a few of these "throw-away" CMSs you're much better off. You can build one for internal use or you can keep code snippets around to reuse in future projects.
–
Mihai StancuDec 19 '12 at 19:00

2 Answers
2

If you're using mysql_query then your site is probably not safe. If you miss even one escape call you're vulnerable, and in any non-trivial application the probability of this is nearly 100%. To be certain you must audit every single database call.

This is why mysql_query is being deprecated and in PHP 5.5.0 will produce all kinds of warnings. Don't use it unless you absolutely have to.

You'd be a lot better off with PDO because if used correctly it's safe by default.

One thing you should do is scan your site with an injection detection tool to catch the most obvious problems if there are any.

Writing secure PHP applications without a framework is going to be very difficult to do. Using a framework at least allows you to leverage what has already been written and tested for you.

First thing that I can say is unsafe: mysql_real_escape_string. The mysql_* functions are going to be deprecated and the use of mysqli or PDO is promoted in stead.

Both mysqli as well as PDO offer prepared statements which under MySQL are theoretically impervious* to MySQL injection attacks without using escape functions.

*Imprevious may be a strong word but avoiding SQL injections is a design feature of prepared statements. However they are not impervious to binary injection attacks or other attack approaches.

If the server compiles the prepared statement into a binary form. And the driver packs and sends a message containing only a list of values (parameters for the prepared statement to be executed with) the result of an SQL Injection attack would be for the fraudulent string to be used as a value - saved inside a mysql record value.

They are not impervious. They just rely on MySQL to have done their security right, which is normally a better bet than to trust yourself. It is still possible to suffer SQL Injections, it is still wise to pre-screen your inputs to ensure they are the right type. intval ints, and so on.
–
DampeS8NDec 19 '12 at 18:56

They are impervious to SQL Injections, they are note entirely secure because they can be attacked by other means.
–
Mihai StancuDec 19 '12 at 18:58

That is not correct, Mihai. Through flaws in how MySQL works, they can suffer SQL Injections. Impervious implies an immunity that it is folly to ascribe any piece of software. Prepared Statements are software and can have been written in a way that would still allow for injection, although that risk is small, small even compared to other kinds of attacks on the same code, but it isn't absent. The risk remains.
–
DampeS8NDec 19 '12 at 19:00

MySQL perhaps - because it stores procedures/functions/prepared-statements in plain text and calls them in plain text. But binary (readily compiled into the internal virtual machine of the db) stored procedures/functions/prepared-statements such as MSSQL and Oracle offer are impervious to the notion/concept of SQL Injection. They may have millions of vulnerabilities to binary code injection, but non regarding SQL Injections.
–
Mihai StancuDec 19 '12 at 19:04

Hey @PeeHaa, I didn't get your meaning. Are you saying that hacking approaches other than SQL Injections are a rare sight nowadays?
–
Mihai StancuDec 19 '12 at 19:06