Test my Sites Security

[Scar0ptics]

I have my site hosted and feel free to let me know of any security holes, if you find any.

The site is: securitybox.ddns.net


This site has a self-signed certificate, so you will have to add an exception. I tested the sites SSL at SSL Labs and I got an "A". Let me know if you find any weaknesses because as of now I think it is solid.

There are vulnerabilities in the CMS and system though; I'm sure of it, as there is no such thing as 100% secure.

[boriz666]

There are immediate problems when editing your profile:

https://securitybox.ddns.net/index.html/?q=user/34/edit

Gives this error:

Error message
PDOException: SQLSTATE[HY000]: General error: 1 Can't create/write to file '/var/tmp/#sql_6d3_0.MAI' (Errcode: 2): SELECT DISTINCT b.* FROM {block} b LEFT JOIN {block_role} r ON b.module = r.module AND b.delta = r.delta WHERE b.status = 1 AND b.custom <> 0 AND (r.rid IN (:rids_0) OR r.rid IS NULL) ORDER BY b.weight, b.module; Array ( [:rids_0] => 2 ) in block_form_user_profile_form_alter() (line 578 of /var/www/html/index.html/modules/block/block.module).

Which gives you some information about where stuff is on server and also gives you the location
of the block.module, from where one can check for other problems.

https://securitybox.ddns.net/index.html ... ock.module

Thats just the first glance, nothing major yet but still good hints on how to move forward.

[Scar0ptics]

Yeah, it's because the server is blocking "write access" for the CMS and the CMS is throwing that error. Emails that are attempted to be sent after account creation are showing an error too.

[Jbraithwaite]

Your site is tighter than a ducks arse.

[-Ninjex-]

Your site is tighter than a ducks arse.

I disagree...
Through the forums, you can add invalid image links. This allows people to request any URL. The fact that user actions aren't protected with XSRF tokens, allows for XSRF to take place.

i.e, and image with the link: https://securitybox.ddns.net/index.html/?q=user/logout will in turn log out any user that views the thread with that message. This could also be used to change account settings, or perform administrative actions on the site admin's behalf; if he views the thread.

If you are logged in, viewing this thread will in fact log you out:
https://securitybox.ddns.net/index.html ... comment-82

[Scar0ptics]

Yes, how would I patch that? The majority of the exploits are within the CMS and theme being used. There was another user from another site that discovered a theme exploit and what you mentioned above as well. I cannot find anything useful.

-- Thu Aug 11, 2016 10:39 am --

There are immediate problems when editing your profile:

https://securitybox.ddns.net/index.html/?q=user/34/edit

Gives this error:

Error message
PDOException: SQLSTATE[HY000]: General error: 1 Can't create/write to file '/var/tmp/#sql_6d3_0.MAI' (Errcode: 2): SELECT DISTINCT b.* FROM {block} b LEFT JOIN {block_role} r ON b.module = r.module AND b.delta = r.delta WHERE b.status = 1 AND b.custom <> 0 AND (r.rid IN (:rids_0) OR r.rid IS NULL) ORDER BY b.weight, b.module; Array ( [:rids_0] => 2 ) in block_form_user_profile_form_alter() (line 578 of /var/www/html/index.html/modules/block/block.module).

I think SElinux is causing this error.

-- Thu Aug 11, 2016 12:53 pm --

On another note I am going to be hosting a cloud server and anyone that wants to collaborate and make this CMS core stronger let me know. I will get everything set up by this weekend.

[-Ninjex-]

Yes, how would I patch that? The majority of the exploits are within the CMS and theme being used. There was another user from another site that discovered a theme exploit and what you mentioned above as well. I cannot find anything useful.

You should implement XSRF Tokens on your forms. These are basically additional hidden form values added to the form. The token is just a randomly generated string that will be known by the server and the client when they request the page.

Client requests page -> Server generates token and adds it to hidden form value -> Client now knows the token and has it in the hidden form value

When the form is submitted, the token value should be checked to ensure that it matches. This will ensure that the client is actually calling this request, and that it's not loaded from an external site or via XSRF. The tokens could be bypassed if XSS is found on the same page as the form, but that's another topic.

In short, if I was to try this attack with XSRF tokens enabled, I would have to pass a valid string in with the form matching the token. If the token is truly random, it should in theory be impossible to predict this token as it's generated when the client requests the page. With an invalid token, the form gets invalidated and will not perform the desired action.

Google about XSRF tokens for more information.

[Scar0ptics]

I did yesterday and I read up on it however I am really limited with the CMS that I am using. All the Content Management Systems have so many holes in the software. The server seems to do just fine, but the weaknesses are all within the default CMS. I just ended up taking the site down because in the end I would end up with what we call a "Frankencore" (all self-made patches). In the long run that will create more problems as other sites have taken that road, and this site is actually one of them (I think).

https://www.drupal.org/node/178896

I will be nuking the server clean and starting over tonight; however, on another note I do have a anonymous proxy and VPN server set up overseas

Let me know if you or anyone else would like to collaborate, so we can come up with something that's more 'solid'.