potential security issues with streber/#2170

Sep 26, 2006 / pixtur
Jan 25, 2010 / julio.coelho

Attached files

No files uploaded
Although some software might be more secure than other, no software is perfectly secure. This page lists common security problems and how streber is affected by them.

Potential security-issuesπ

estimating the potential risk for streber in brackets...

Stealing cookies (low)π

Stealing the cookie either by direct access of another persons computer or by remote access is a very bad problem.

To prevent this, streber does:
  • add time of cookie-set to person-table
  • recalculate the cookie-string after each successful validation (if this CHECK_IP_ADDRESS is on)
  • 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.

Cross-Site Request Forgery (high)π

This requires a Shared-Secret for all modifying requests. We implemented this in version v0.09 but adding random tokens to each form. This random token is stored on the server side and validated on submit.

Cross Site Scripting (low)π

To prevent from intrusion 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:


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.

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

All php-files are starting with a line that relinks to index.php on direct access.

<?php if(!function_exists('startedIndexPhp')) { header("location:../index.php"); exit;}

register globals (low)π

Many 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.

Forging form-data (low)π

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.)
  • a checksum is build from all important hidden form parameters. A hash of those checksums and the key=>value pairs is stored for each user in "_tmp".
This attack requires an valid login or a public guest account.

SQL injection (low)π

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

SQL sort spoofing aka ORDER BY injection (low)π

Attackers could add SQL-code to the order by code to spoof secret database information. As with streber v0.06 all ORDER BY strings are cleared by the function std/common.inc.php -> getOrderByString().

Uploading bad code (low)π

To avoid execution of uploaded files on the server side, streber converts the local filenames to alphanumeric strings.

Code injection into preg_match (low)π

To avoid injecting bad code into search requests and preg_match()-patterns, the strings are cleaned before usage.

Additional measures probably comming in future versions:π


madlyr:We should add security mailing list which could warn people about security issue

12 years ago

Any idea which software to use?

Maybe we could add streber to some security portals which informs about known security issues too.