Security

From No3wiki

Potential security-issues

Important: an updated version can be fould at: http://streber.pixtur.de/index.php?go=taskView&tsk=2170

estimating the potential risk for streber in brackets...

Table of contents

1 Stealing cookies (low)

2 Cross-Site Request Forgery (high)

3 Cross Site Scripting (low)

4 spying php-code when using other file-extensions than .php (mid)

5 register globals (low)

6 forging form-data (high)

7 SQL injection (low)

8 Additional measures

9 Additional Information

[edit]

Stealing cookies (low)

Currently the cookies are a direct checksum of nickname and password, which means that a cookie-string can only be made invalid by changing the password or renaming the user. This is not desireable and should be fixed by adding a lifetime (and optionally the ip-adress) to the cookie-string:

~~add time of cookie-set to person-table~~
~~recalc the cookie-string after each successful validation~~
~~before validation, check if the cookie-string is still valid~~
~~optionally check if user's ip has changed (the ip-adresse can be forged, but this will increase the rate at which users have to re-enter their password).~~

As with version v0.057 all of those measures have been done. Still there is a risk of stealing the activation code inside notification-mails. With this code, evil persons could login and get access to the persons profil-setting.

[edit]

Cross-Site Request Forgery (high)

This requires a Shared-Secret for all modifying requests. This will probaly be implemented in v0.05x

[edit]

Cross Site Scripting (low)

To prevent from introdusion of evil code, ALL referred variables are stripped from html-tags. This might not be desired in all situation e.g. if you want to poste code fragments. To adjust this behaviour you can add following line to the customize.inc:

confChange('CLEAN_REFERRED_VARS', 'HTML_ENTITIES');

This attack requires an valid login or a public guest account.

Update: As with v0.06 all information entered by users is converted into valid html-code. (like > is converted to >). This disables html-formatting and js-injection.

[edit]

spying php-code when using other file-extensions than .php (mid)

Some servers display files ending with .inc as plain text. Of course this is not desirable. "db_settings.inc" has already been renamed to "db_settings.php".

All other files are destributed under GPL, you can read them anyway.

Nevertheless with v0.05x all "*.inc"-files will be renamed to "*.php"

[edit]

register globals (low)

Some providers still have register globals turned on. To prevent from intrusion the global namesspace is cleaned at the beginning of index.php. All other pages, which might be accesses directly, are referred to index.php.

[edit]

forging form-data (high)

An evil attacker might try to call functions like "personEditSubmit" with a set of manipulated form parameters. To prevent this we do

check if current user has been authenticated
current user has enough rights to edit the person
if security-settings of person are passed, we check if current user have enought rights to account and right-details for person (password, can_login, user_rights, etc.)

This attack requires an valid login or a public guest account.

[edit]

SQL injection (low)

All sql-querries are executed by the DB-objects with does escape quotes. Unless local sql-querres are done (or the install directory has not been removed), the risk of sql-injection should be low.

[edit]