fixing xss in exhibits editor

[Alexeyan]

The exhibits of this cms don't really sanitize the userinput for javascript code, allowing potential XSS to happen. A potential target for XSS could be the ndxz_access and ndxz_hash cookies, allowing an attacker to steal cookies and impersonate other users.

This fix is only exemplary for simple javascript tags in the text editor. I would recommend including a anti-xss library and sanitizing every user input.

Best regards, Alex

[Vaska]

Thanks Alexeyan - I can use help in this area. There is some santization at the PHP end of things but perhaps it's not wholly sufficient. I'll have a look and merge this soon. ;)

[Alexeyan]

I would recommend using a maintained xss-filter package. Like this one for example https://github.com/cure53/DOMPurify and use it on every user-submitted input field.

[Zegnat]

A potential target for XSS could be the ndxz_access and ndxz_hash cookies, allowing an attacker to steal cookies and impersonate other users.

The proper solution to this is probably to mark session cookies HttpOnly. We are talking compatibility all the way back to IE6 here, this is not new. Cookies that are marked HttpOnly cannot be read by JavaScript and are thus pretty safe from being read through XSS.

For PHP this is the session.cookie-httponly configuration value, and can also be set through the more easily accessible (from Indexhibit’s side) session_set_cookie_params-function:

$currentSettings = session_get_cookie_params();
session_set_cookie_params(
    $currentSettings['lifetime'],
    $currentSettings['path'],
    $currentSettings['domain'],
    $currentSettings['secure'], // Secure (cf. https://www.owasp.org/index.php/SecureFlag)
    true                        // HttpOnly
);

(I was just scrolling by and thought I’d drop this in. Been a long time since I looked at Indexhibit, maybe it is about time again.)

[Vaska]

Thanks for this info.

Sent from where ever I am right now....

On 22 Feb 2019, at 9:32 AM, Martijn van der Ven [email protected] wrote:

A potential target for XSS could be the ndxz_access and ndxz_hash cookies, allowing an attacker to steal cookies and impersonate other users.

The proper solution to this is probably to mark session cookies HttpOnly. We are talking compatibility all the way back to IE6 here, this is not new. Cookies that are marked HttpOnly cannot be read by JavaScript and are thus pretty safe from being read through XSS.

For PHP this is the session.cookie-httponly configuration value, and can also be set through the more easily accessible (from Indexhibit’s side) session_set_cookie_params-function:

$currentSettings = session_get_cookie_params(); session_set_cookie_params( $currentSettings['lifetime'], $currentSettings['path'], $currentSettings['domain'], $currentSettings['secure'], // Secure (cf. https://www.owasp.org/index.php/SecureFlag) true // HttpOnly ); (I was just scrolling by and thought I’d drop this in. Been a long time since I looked at Indexhibit, maybe it is about time again.)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.