Stored XSS within article creation

[prodigysml]

A writer or the administrator can write javascript within the page, which can then be used to steal other user's session tokens (actually quite possible as the session token doesn't have HttpOnly enabled). Adding something like , in the article's content stores the payload on the server.
Then any user who visits the page is affected by the payload.

I would advise HTML encoding the user input and also setting the HttpOnly flag on the session token.

[bazooka07]

Yes.
By default, session.cookie_httponly is empty in php.ini.

useful link:
http://php.net/manual/en/session.configuration.php#ini.session.cookie-httponly

[fgeek]

I don't think it is a issue when administrator can input any JavaScript to the articles, but it's an issue that regular writer can do so or are all writers automatically fully trusted? Missing HttpOnly is separate issue, but should be fixed as well. This also affects Debian unstable.

[pluxml]

@bazooka07 as-tu une suggestion pour corriger session.cookie_httponly ?

[bazooka07]

Je n'ai pas fait d'essais mais a priori la fonction session_set_cookie_params devrait faire le job avec httponly=true.
http://php.net/manual/fr/function.session-set-cookie-params.php
En profiter pour régler lifetime qui par défaut est égal à 0. 1 à 2H pour rédiger un article devrait suffire.

[bazooka07]

En complement du précèdent post, voici un article à lire:
https://phackt.com/xss-cors-csrf-partie-2-xss-cookies-session
Et donc, tester ceci :

<?php
const LIFETIME = 2 x 60 x 60; # secondes
session_set_cookie_params(LIFETIME, $plxAdmin->racine.'core/admin/', $_SERVER['SERVER_NAME'], isset($_SERVER["HTTPS"]), true);
?>

Autre lien intéressant:
https://php.earth/docs/security/intro
Voir en particulier "Directory traversal (path injection)". A rapprocher de la valeur de PLX_ROOT.
PLX_ROOT est à bannir de toutes les urls.
Autre souci : config.php ne devrait pas être à la racine du site. Le cacher dans le dossier core.

[NicoleG25]

Regarde que CVE-2017-1001001 assigné à cette vulnérabilité,

était-ce réparé?
@bazooka07

[haruka-7]

Hi @NicoleG25, I think we can have a first fix (PR #357) for the next PluXml release wich is planned for this week.