Translation PHP Security Tips (top)

Recently more concerned about the security of PHP, many domestic developers, especially PHP beginners, many times only to meet the function is realized, the discussion of the safety of a little even indifferent. Such consequences are serious, such as flooding of SQL injection, and even directly downloaded database connection files ... This article is from Cal Evans published Devzone series of topics: PHP Security Tip (Safety advice/tips) Although not the latest article, but the mention of many of the principles of things and classic practice is still worthy of attention, is definitely worth reading a good article, to use this, Hope to give you a little help, establish a good sense of safety, understand the necessary preventive measures. The text added to my understanding and comments where the place has been annotated, the first translation, the improper place is welcome to point out. Thank you

, the original book a total of 21 suggestions, which is the upper part of the translation.

PHP Security Tip #1

Cal Evans (Editor) 2 comments Thursday, March 1, 2007

Looking for the security silver bullet? I ' ve got bad news for you, there isn ' t one. Security take an ongoing effort and a lot of little things instead of one of the one big one. This is month we are kicking off a new feature on Devzone and "security Tip of the Week". To kick this is right we'll post one a day during March. Some of these tips would be specific things can do, Some'll be general concepts you need to is aware of, all of them would be brief. So without further comment, here's the "the" security Tip of the Week.

Comment

Mailing LIST

1:17pm UTC Rob [Unregistered]

It can often be a good idea to join the relevant mailing list. Can find the announcement list for new releases of PHP below.

http://www.php.net/mailing-lists.php

------------------------------------------------------------------------------

PHP Security Small recommendation 1

If you're looking for a silver bullet in security (in Western Christianity, only the silver bullet hits the heart to Kill the Demon (vampire Werewolf). In Fred Brooks's famous books on software engineering, the man-moon myth and the No silver bullet, the growing software development project is likened to an uncontrollable monster, that is, to have the same technology to completely solve the problem as the silver bullet kills the demon. I have a bad news to tell you, no silver bullets. Security issues require continuous effort and a lot of trivial work rather than a single big problem, and this month we will start a new topic, "A week of security tips," as a starting point, during March, we will issue a daily proposal. Some of the suggestions will be specific things you can do, others you need to pay attention to, and all of the suggestions are brief, okay, gossip less, and then start our first week of security tips.

Comments:

Mailing list

Getting involved in mailing lists is a good idea, and you can find the latest announcements list of PHP announcements at the following address!

http://www.php.net/mailing-lists.php

------------------------------------------------------------------------------

PHP Security Tip #2

Cal Evans (Editor) 3 Comments Friday, March 2, 2007

Security by obscurity are no security in all. On the other hand you don ' t want to give away information about your site. Today's tip is a simple one but one this is often overlooked in production environments.

Make sure don't display errors and potentially leak information about your site.

Simply setting Display_errors = off in your php.ini of your production server would prevent you from leaking information th At may give intruders hints to the structure of your system. By default, Display_errors = On.

Can find more information and error Reporting options in the manual ' s error handling and Logging functions N section.

------------------------------------------------------------------------------

PHP Security Recommendations

Using hidden information to ensure that security does not fundamentally play a security role (obscurity by the "no"), but on the other hand you do not want to disclose your site information.

Today's recommendations are simple, but they are often overlooked in a production environment.

Be sure not to display error messages and potential leaks from the site

As long as simply in the production server php.ini set display_errors = off, you can prevent the leakage of system structure information, allowing intruders. The default setting is: Display_errors = on.

In the manual error handling and log functions section, you can find more information and error reporting options.

------------------------------------------------------------------------------

PHP Security Tip #3

Cal Evans (Editor) 1 Comment Monday, March 5, 2007

Being security conscious are a good thing but that alone won ' t solve the problem. Developers have to is vigilant when it comes to security. Even then can ' t do it alone. Today's security tip reminds for this.

Since your application may is harboring security vulnerabilities so have not been exposed to, third-party security s Oftware or services should is considered to help bring a fresh perspective and find overlooked weaknesses.

As a developer you should have tools into your toolbox that'll help you find security vulnerabilities in your applications . Tools like chorizo'll help your by performing automated scans of your code. Programs like Phpsecinfo'll help you ensure this your environment is configured properly.

Using tools like this and other scanning tools should is the only thing your do to ensure security. They are however, a important part of the mix. Let trusted projects and vendors help you with build and maintain secure applications.

------------------------------------------------------------------------------

PHP Security Recommendations #3

Security awareness is a good thing, but it does not solve the problem itself, the developer must always be vigilant on security issues, although that is not enough, today's security advice to remind you:

Because your application may have a lot of hidden security concerns, using Third-party security software or services can help you make a clear perspective on your application and find overlooked deficiencies.

As a developer, your toolbox should have tools that can help you detect application security vulnerabilities. Tools like chorizo, which automatically scan your code for problems, and programs like Phpsecinfo ensure the proper configuration of the environment.

For security purposes, it is not enough to use these tools or other scanning tools, but they are an important part of the various combination measures. The projects and vendors that are worth relying on will help you build and maintain secure applications.

------------------------------------------------------------------------------

PHP Security Tip #4

Cal Evans (Editor) 7 comments Tuesday, March 6, 2007

"Security through obscurity are no security in all." So the adage goes. However, the flip side of that coin are, obscurity, when used as part of a overall strategy, is a good thing. There ' s no sense in making things any easier to those with malicious. That's brings us to my security tip.

Give files and folders with critical information non-default names.

Don ' t rely on obscure names to keep your application safe. Should always check permissions, test for vulnerabilities with testing tools and keep a eye on your log files for SUS Picious activity. When designing your applications and Web sites though, don ' t make it easy for bad people. Don ' t use the default or common names for your files and directories.

Do your have a security tip your would like to share? A Nugget of security truth you have gleaned through the "A" or life ' s School of Hard knocks? Log-in and click the Contribute button in the upper right hand corner.

------------------------------------------------------------------------------

PHP Security Recommendations #4

As the proverb goes, "The use of hidden information to ensure security does not fundamentally play a security role", but on the other hand, hiding information as part of a security overall strategy is a good thing, through. For those who have a bad heart to make things simple meaningless, from here to our safety tips today.

Instead of trying to rely on obscure naming to keep your application safe, you should always check permissions, use test tools to check for pitfalls, and watch for suspicious activity log files. However, when designing applications and websites, do not provide a simple opportunity for bad people to do evil things. Do not use the default or generic naming for files or directories.

Do you have any security tips you'd like to share? Through the study of the Golden Creed, or in real life after favour lessons? Welcome to login and click on the top right corner of the contribution button and we share.

------------------------------------------------------------------------------

PHP Security Tip #5

Cal Evans (editor) 1 Comment Wednesday, March 7, 2007

The mission requiring the programmer to the outside of the parameters. It's not enough the say in your mind "does the Do what I want it to do?" For you also have to take into Considerati On ' What else can people use it for and doing I want to allow that? ' Today's security tip is a proverb the all programmers should have to recite daily.

Never Trust the user.

It ' s a sad fact of life but users are evil. Users want nothing more than to find a way to exploit your application. As soon as we your guard down and start thinking "I ' m only selling small stuffed animals so how evil can I users rea Lly be? "You ' ve lost the battle.

Ok, maybe it ' s not quite that dire but your do have to keep a wary eye on some of your users. That's where the second proverb the all programmers should recite daily comes in.

Filter Input, Escape Output

Yes, FIEO (OK, it's not as cool sounding as GIGO) is one of the mantras this all security minded programmers live by.

------------------------------------------------------------------------------

PHP Security Recommendations #5

PHP Security is an ongoing task that requires programmers to think about the outside of application parameters, and now, just thinking, "Does it (apps) do what I want it to do?" You have to think about "what else can people do with it and do I allow them to do that?" Today's security advice is a motto that all programmers must recite every day:

Never trust a user. (Never trust the user)

The user is evil, though it is a sad thing in real life, they do everything they can to break your application, as long as you take it lightly and think, "I'm just selling a little stuffed animal." (a metaphor for developing applications), can my users really be so evil?, Then you've lost the fight.

Well, maybe it's not that scary, but you still need to be wary of a subset of the users. The second of all programmers must recite every day the maxim appeared

Filter input, encoded output (filter input, Escape output)

Yes, FIFO (well, it's not as cool as Gigo), it's one of the curses that all security-conscious programmers rely on to survive.

------------------------------------------------------------------------------

PHP Security Tip #6

Cal Evans (Editor) 5 comments Thursday, March 8, 2007

The topic of writing secure applications in PHP covers more than just writing good PHP code. Most applications make use of a database of some kind. Many times, vulnerabilities which affect the entire application, are introduced when building the SQL code. Today's Tip of the day deals with one easy solution developers can implement.

When dealing with numbers in a SQL query, always cast.

Even if you are filtering your input, a good and easy to implement safety-measure-to-cast all numeric values in the SQL Statement. Take For example the following code.

$myId = Filter_var ($_get[' id '],filter_validate_int);

$sql = ' SELECT * FROM table WHERE id = '. $myId;

Even though you are applying the native PHP filters built to PHP 5.2, there is something additional your can do. Try this instead.

$myId = Filter_var ($_get[' id '],filter_validate_int);

$sql = ' SELECT * FROM table WHERE id = '. (int) $myId;

This is final cast of the variable to a int removes any doubt about what would be passed to MySQL. The example above is purposefully simplified. In real-life situations, the code would is more complex and the chance for error much greater. By applying the final cast to in building the SELECT statement, your are adding one more level of safety into your applicat Ion.

------------------------------------------------------------------------------

PHP Security Recommendations #6

The topic of writing a secure PHP application is much more than writing good PHP code, and most applications will be used in this or that way, and many times, in the process of building the SQL code, the security implications of the entire application are drilled in.

When working with numbers in SQL queries, be sure to cast (cast)

Even in filtering input, a simple and useful security measure is to cast all numeric type values in an SQL statement. As shown in the following code

$myId = Filter_var ($_get[' id '],filter_validate_int);

$sql = ' SELECT * FROM table WHERE id = '. $myId;

Even if you use the PHP5.2 built-in native PHP filter (refer to the latest PHP manual "Some old Chinese version of the PHP manual does not have this chapter" in the section "Data filtering"), you can also do something else. Try replacing the following statement:

$myId = Filter_var ($_get[' id '],filter_validate_int);

$sql = ' SELECT * FROM table WHERE id = '. (int) $myId;

The variables in the final model (final cast) are projected as integers (int), to remove all the confusion about what was passed to MySQL, the examples are deliberately simplified, and in reality, the code is more complex and the chances of error are more, depending on the final model to build the SELECT statement, Your code has a level of security.