[Webapps-common-discuss] [commit] r137 - webapps-common/trunk/doc
Neil McGovern
neilm at alioth.debian.org
Mon Sep 7 18:04:02 UTC 2009
Author: neilm
Date: 2009-09-07 18:04:00 +0000 (Mon, 07 Sep 2009)
New Revision: 137
Modified:
webapps-common/trunk/doc/Webapps-Policy-Manual-DRAFT.sgml
Log:
Merge suggested changes from d-w at l.d.o prior to push to policy
Modified: webapps-common/trunk/doc/Webapps-Policy-Manual-DRAFT.sgml
===================================================================
--- webapps-common/trunk/doc/Webapps-Policy-Manual-DRAFT.sgml 2007-09-07 15:39:25 UTC (rev 136)
+++ webapps-common/trunk/doc/Webapps-Policy-Manual-DRAFT.sgml 2009-09-07 18:04:00 UTC (rev 137)
@@ -116,7 +116,7 @@
<p>Architecture-independant
content requiring server
interpretation. <em>Most PHP
- applications are based from
+ applications are based on
this type of content.</em>
<tag><item>
<p><strong>Dynamically executed content</strong>
@@ -176,7 +176,7 @@
assumption about how the administrator
has arranged the file hierarchy outside of
the FHS by placing files in non-standard
- places such as /srv, /var/www or /usr/local.
+ places such as /home, /srv, /var/www or /usr/local.
<p>
Specifically, the following table should
serve as a guideline for the placement
@@ -192,7 +192,9 @@
<tag>Application-specific include files
<item>A unique subdirectory of <file>/usr/share/<var>PACKAGE</var></file>
<tag>Other static data, and helper scripts that don't belong in users' paths
- <item>A unique subdirectory of <file>/usr/share/<var>PACKAGE</var></file>
+ <item>A unique subdirectory of <file>/usr/share/<var>PACKAGE</var></file>, for example <var>htdocs</var>
+ <tag>User uploaded content
+ <item>A unique subdirectory of <file>/usr/lib/<var>PACKAGE</var></file>
<tag>Persistent application data, Cached/regenerated application data, rrd, mrtg and other database files
<item>See <url id="http://people.debian.org/~seanius/policy/dbapp-policy.html/" name="database application policy">.
<tag>Site configuration (settings/passwords)
@@ -209,7 +211,7 @@
<p>
In-line with standard FHS policy, any
files that require being edited by the
- local administrator (for information such
+ local administrator (such
as "themes" or credentials to a database)
must be located under <file>/etc</file>,
in a directory specific to the package
@@ -295,7 +297,7 @@
it should either follow the previously
mentioned guidelines for configuration and
customizable content or use a subdirectory
- of <file>/usr/local/<var>PACKAGE</var></file>.
+ of <file>/usr/local/share/<var>PACKAGE</var></file>.
Managing the latter is outside the scope
of this document.
<sect id="issues-database">Database issues
@@ -311,15 +313,13 @@
<sect id="security-php">Security measurements
<p>
- PHP applications must not depend on
- the "register_global" setting turned
- on in Apache or other httpds.
- <p>
- PHP applications should take extra
- care not to use internal variables
- before their initialisation, in case
- "register_global" is turned on by the
- administrator.
+ Web applications that are configured by default to be
+ publically accessable must not rely on features or
+ particular configurations of a webserver or scripting engine
+ that are considered to be insecure. For example,
+ applications must not depend on the "register_globals" setting
+ in the PHP scripting engine
+
<!-- p>
Include files should not emit any
output, not even error messages, in
@@ -330,16 +330,16 @@
Web-based applications should not
blindly trust any user-provided data.
- Before emitting them, the data need to
+ Before emitting them, the data needs to
be checked for cross-site scripting
attempts, i.e. HTML code needs to be
- escaped. Input for databases need to
+ escaped. Input for databases needs to
be checked against SQL-injection
attempts, i.e. quotes need to be
escaped. User-driven arguments to any
file or permission related functions
need to be checked against information
- disclosure, i.e. input need to be
+ disclosure, i.e. input needs to be
checked for ways to escape the
intended path on the filesystem.
@@ -356,7 +356,7 @@
location. Scripts intended for execution or
interpretation via the web must exist in
locations where their underlying source code
- can be directly retrieved.
+ can not be directly retrieved.
<p>This may require to split upstream source
into two directories and adjusting the
include path or statements.
@@ -395,6 +395,14 @@
should exist outside of any web-accessible directory, as many
security-related problems in poorly written web applications
are the direct result of not doing so.
+ <p>
+ When applicable, site-wide include files should adhere to the rules
+ and conventions of the respective language policy documents.
+ Otherwise, a directory location similar to the application-specific
+ includes path can be used. The files should be provided in a
+ package separate from any web application or otherwise unneeded
+ dependencies, to allow for re-use and eliminate multiple copies of
+ the code in different packages.
<sect id="php">PHP
<p>
@@ -507,8 +515,8 @@
<var>SERVER_NAME</var> and
<var>HTTP_HOST</var> can be used to
provide applications with enough
- information to find what config
- file/script it should use
+ information to find out which config
+ file/script should be used
<item>
For PHP applications under Apache, one
can use "php_value auto_prepend_file"
@@ -524,7 +532,7 @@
<p>
The static and dynamically interpreted
content of a web application should be
- accessable from at or underneath
+ accessable from, at or underneath
<tt>http://<var>SERVERNAME</var>/<var>PACKAGE</var></tt>
The package's dynamically executed content may
also be accessible from
@@ -536,7 +544,7 @@
recommended that package maintainers use
pre-existing tools to aid in packaging web
applications. This centralizes the effort not
- only for the packageers themselves, but also
+ only for the packagers themselves, but also
for translators and results in a much more
consistant feel for users of web applications:
@@ -568,14 +576,15 @@
<item> perform all operations from within the standard flow of debian package maintainance (no additional skill is required of the local admin)
</list>
- <sect id="tools-webapps">webapps-common
- <p> <package>webapps-common</package>provides a centralized
+ <!-- sect id="tools-webapps">webapps-common
+ <p> <package>webapps-common</package> provides a centralized
set of tools and procedures for configuring web applications,
webserver extensions, and other packages related to the world
of web applications. Details of this package, and it's implementation
can be found in the <url id="http://webapps-common.alioth.debian.org/draft-wac/html" name="webapps-common developer's guide">.
The <package>webapps-common</package> package may be used instead of
- registering applications directly with the webserver, as described in
+ registering applications directly with the webserver, as described in the
<em>Registering and unregistering an application with web servers</em> section.
+ -->>
</book>
More information about the Webapps-common-discuss
mailing list