@SR-mkuhn opened this issue on July 9th 2015

If an attacker invokes an error like #8268 (he doesn't need to be authenticated for that) , a notification will be saved in the data field of his session. As those notifications are stored until they are displayed (but aren't), the data field grows over time. This can be used to fill hdd space or database space (if database session handling is active).

If database replication (mysql) is activated binlog grows very quick too, and uses a lot of hdd space (all of it).

A solution could be a limitation of notifications based on loginstatus.

@tsteur commented on July 13th 2015

Limiting the number of notifications sounds like a good idea in general :+1:

@mattab commented on July 15th 2015

For security reasons it sounds like a very good idea to limit number of notifications. @tsteur do you have any suggestion how this could work?

@mattab commented on July 16th 2015

Also for performance reasons this issue is important, see #8308

@tsteur commented on July 16th 2015

I'm not sure how notifications are implemented right now (especially re logging). At least initially they were stored in an array in the session so we could simply limit the number of notifications by using array_splice or so.

@mnapoli commented on July 19th 2015

especially re logging

FYI logging simply uses the notification system, so it works like the rest of the notifications (which I don't know how it works :p that was only my 2c).

This issue was closed on July 20th 2015
Powered by GitHub Issue Mirror