[PHP-DOC] cvs: phpdoc /en/security index.xml intro.xml
betzMon Jan 26 08:52:19 2004 EDT Modified files: /phpdoc/en/security index.xml intro.xml Log: split also the intro from index.xml. Thanks Goba http://cvs.php.net/diff.php/phpdoc/en/security/index.xml?r1=1.67&r2=1.68&ty=u Index: phpdoc/en/security/index.xml diff -u phpdoc/en/security/index.xml:1.67 phpdoc/en/security/index.xml:1.68 --- phpdoc/en/security/index.xml:1.67 Mon Jan 26 08:22:25 2004 +++ phpdoc/en/security/index.xmlMon Jan 26 08:52:18 2004 @@ -1,44 +1,9 @@ - + Security - - - PHP is a powerful language and the interpreter, whether included - in a web server as a module or executed as a separate - CGI binary, is able to access files, execute - commands and open network connections on the server. These - properties make anything run on a web server insecure by default. - PHP is designed specifically to be a more secure language for - writing CGI programs than Perl or C, and with correct selection of - compile-time and runtime configuration options, and proper coding - practices, it can give you exactly the combination of freedom and - security you need. - - - As there are many different ways of utilizing PHP, there are many - configuration options controlling its behaviour. A large - selection of options guarantees you can use PHP for a lot of - purposes, but it also means there are combinations of these - options and server configurations that result in an insecure - setup. - - - The configuration flexibility of PHP is equally rivalled by the - code flexibility. PHP can be used to build complete server - applications, with all the power of a shell user, or it can be used - for simple server-side includes with little risk in a tightly - controlled environment. How you build that environment, and how - secure it is, is largely up to the PHP developer. - - - This chapter starts with some general security advice, explains - the different configuration option combinations and the situations - they can be safely used, and describes different considerations in - coding for different levels of security. - - + &security.intro; &security.general; &security.cgi-bin; &security.apache; http://cvs.php.net/diff.php/phpdoc/en/security/intro.xml?r1=1.1&r2=1.2&ty=u Index: phpdoc/en/security/intro.xml diff -u phpdoc/en/security/intro.xml:1.1 phpdoc/en/security/intro.xml:1.2 --- phpdoc/en/security/intro.xml:1.1Mon Jan 26 08:22:25 2004 +++ phpdoc/en/security/intro.xmlMon Jan 26 08:52:18 2004 @@ -1,3 +1,59 @@ - + + + PHP is a powerful language and the interpreter, whether included + in a web server as a module or executed as a separate + CGI binary, is able to access files, execute + commands and open network connections on the server. These + properties make anything run on a web server insecure by default. + PHP is designed specifically to be a more secure language for + writing CGI programs than Perl or C, and with correct selection of + compile-time and runtime configuration options, and proper coding + practices, it can give you exactly the combination of freedom and + security you need. + + + As there are many different ways of utilizing PHP, there are many + configuration options controlling its behaviour. A large + selection of options guarantees you can use PHP for a lot of + purposes, but it also means there are combinations of these + options and server configurations that result in an insecure + setup. + + + The configuration flexibility of PHP is equally rivalled by the + code flexibility. PHP can be used to build complete server + applications, with all the power of a shell user, or it can be used + for simple server-side includes with little risk in a tightly + controlled environment. How you build that environment, and how + secure it is, is largely up to the PHP developer. + + + This chapter starts with some general security advice, explains + the different configuration option combinations and the situations + they can be safely used, and describes different considerations in + coding for different levels of security. + + + +
[PHP-DOC] cvs: phpdoc /en/security index.xml
didou Tue Jan 6 04:22:21 2004 EDT Modified files: /phpdoc/en/security index.xml Log: more CS Index: phpdoc/en/security/index.xml diff -u phpdoc/en/security/index.xml:1.65 phpdoc/en/security/index.xml:1.66 --- phpdoc/en/security/index.xml:1.65 Sat Dec 20 20:23:01 2003 +++ phpdoc/en/security/index.xmlTue Jan 6 04:22:21 2004 @@ -1,5 +1,5 @@ - + Security @@ -920,9 +920,9 @@ Attacking Variables with a custom HTML page @@ -947,10 +947,10 @@ Exploiting common debugging variables
[PHP-DOC] cvs: phpdoc /en/security index.xml
derek Tue Dec 9 14:07:42 2003 EDT Modified files: /phpdoc/en/security index.xml Log: fixed #25559 Index: phpdoc/en/security/index.xml diff -u phpdoc/en/security/index.xml:1.62 phpdoc/en/security/index.xml:1.63 --- phpdoc/en/security/index.xml:1.62 Tue Sep 30 04:33:48 2003 +++ phpdoc/en/security/index.xmlTue Dec 9 14:07:42 2003 @@ -1,5 +1,5 @@ - + Security @@ -492,26 +492,26 @@ Nowadays, databases are cardinal components of any web based application by enabling websites to provide varying dynamic content. Since very sensitive -or secret informations can be stored in such database, you should strongly -consider to protect them somehow. +or secret information can be stored in a database, you should strongly +consider protecting your databases. To retrieve or to store any information you need to connect to the database, -send a legitimate query, fetch the result, and close the connecion. +send a legitimate query, fetch the result, and close the connection. Nowadays, the commonly used query language in this interaction is the Structured Query Language (SQL). See how an attacker can tamper with an SQL query. -As you can realize, PHP cannot protect your database by itself. The +As you can surmise, PHP cannot protect your database by itself. The following sections aim to be an introduction into the very basics of how to access and manipulate databases within PHP scripts. -Keep in mind this simple rule: defence in depth. In the more place you -take the more action to increase the protection of your database, the less -probability of that an attacker succeeds, and exposes or abuse any stored -secret information. Good design of the database schema and the application +Keep in mind this simple rule: defense in depth. The more places you +take action to increase the protection of your database, the less +probability of an attacker succeeding in exposing or abusing any stored +information. Good design of the database schema and the application deals with your greatest fears. @@ -519,7 +519,7 @@ Designing Databases The first step is always to create the database, unless you want to use - an existing third party's one. When a database is created, it is + one from a third party. When a database is created, it is assigned to an owner, who executed the creation statement. Usually, only the owner (or a superuser) can do anything with the objects in that database, and in order to allow other users to use it, privileges must be @@ -536,14 +536,14 @@ application with very limited rights to database objects. The most required privileges should be granted only, and avoid that the same user can interact with the database in different use cases. This means that if - intruders gain access to your database using one of these credentials, + intruders gain access to your database using your applications credentials, they can only effect as many changes as your application can. You are encouraged not to implement all the business logic in the web - application (i.e. your script), instead to do it in the database schema + application (i.e. your script), instead do it in the database schema using views, triggers or rules. If the system evolves, new ports will be - intended to open to the database, and you have to reimplement the logic + intended to open to the database, and you have to re-implement the logic in each separate database client. Over and above, triggers can be used to transparently and automatically handle fields, which often provides insight when debugging problems with your application or tracing back @@ -557,11 +557,11 @@ You may want to estabilish the connections over SSL to encrypt client/server communications for increased security, or you can use ssh to encrypt the network connection between clients and the database server. - If either of them is done, then monitoring your traffic and gaining - informations in this way will be a hard work. + If either of these is used, then monitoring your traffic and gaining + information about your database will be difficult for a would-be attacker. @@ -584,16 +584,16 @@ The easiest way to work around this problem is to first create your own encryption package, and then use it from within your PHP scripts. PHP - can assist you in this case with its several extensions, such as Mcrypt and Mhash, covering a wide variety of encryption - algorithms. The script encrypts the data be stored first, and decrypts - it when retrieving. See the references for further examples how + algorithms. The script encrypts the data before inserting it into the database,
[PHP-DOC] cvs: phpdoc /en/security index.xml
ali Sat Aug 23 05:34:25 2003 EDT Modified files: /phpdoc/en/security index.xml Log: added XHTML entity, see #25208 for more information Index: phpdoc/en/security/index.xml diff -u phpdoc/en/security/index.xml:1.60 phpdoc/en/security/index.xml:1.61 --- phpdoc/en/security/index.xml:1.60 Fri Aug 22 08:37:02 2003 +++ phpdoc/en/security/index.xmlSat Aug 23 05:34:25 2003 @@ -1,5 +1,5 @@ - + Security @@ -947,7 +947,7 @@ Exploiting common debugging variables
[PHP-DOC] cvs: phpdoc /en/security index.xml
didou Fri Aug 22 08:37:02 2003 EDT Modified files: /phpdoc/en/security index.xml Log: fixing #25208 Index: phpdoc/en/security/index.xml diff -u phpdoc/en/security/index.xml:1.59 phpdoc/en/security/index.xml:1.60 --- phpdoc/en/security/index.xml:1.59 Thu Aug 21 10:41:32 2003 +++ phpdoc/en/security/index.xmlFri Aug 22 08:37:02 2003 @@ -1,5 +1,5 @@ - + Security @@ -947,7 +947,7 @@ Exploiting common debugging variables
[PHP-DOC] cvs: phpdoc /en/security index.xml
ali Thu Aug 21 10:41:32 2003 EDT Modified files: /phpdoc/en/security index.xml Log: fixed typo (bug #25191) Index: phpdoc/en/security/index.xml diff -u phpdoc/en/security/index.xml:1.58 phpdoc/en/security/index.xml:1.59 --- phpdoc/en/security/index.xml:1.58 Fri Jun 20 15:21:59 2003 +++ phpdoc/en/security/index.xmlThu Aug 21 10:41:32 2003 @@ -1,5 +1,5 @@ - + Security @@ -219,7 +219,7 @@ Case 3: setting doc_root or user_dir To include active content, like scripts and executables, in the - web server document directories is sometimes consider an insecure + web server document directories is sometimes considered an insecure practice. If, because of some configuration mistake, the scripts are not executed but displayed as regular HTML documents, this may result in leakage of intellectual property or security
