Settings injection possibilities
|Reported by:||qnrq||Owned by:|
I discovered that I could manipulate the stored settings data by simply sending different data than what the _skin select would list. When presenting the available options (the available directories in the skin folder), the loop outputs like this:
<select name="_skin" id="rcmfd_skin"> <option value="foo">foo</option> </select>
If I would tamper the posted data and replace foo with bar, bar would be stored, in my case in MySQL, instead, even though I have no skin installed called bar. This is possible since the only performed check on available skins is done when presenting the available options to the user. Since there is no check on the received data when the settings are being saved this creates injection possibilities.
This patch applies an is_dir() check on a statical skin directory (./skins/) and removes unexpected commas. With improper permissions this may still allow directory traversals but I figured it's a smaller risk to take than risking e.g. a second order sql injection.
I haven't tried to exploit this vulnerability as I figure there are more alternative backend setups than I have time to try against.