ProcessWire Security Check and Suggestions

[omshah]

Hello Everyone,

For our KIT325 Cybersecurity Project, we recently checked the security of ProcessWire CMS, a system used for managing website content. We wanted to see if its default settings are secure enough based on the OWASP Top 10 standards, which are common web security guidelines. Here’s a quick look at what we found and what could be improved:

Blocking Brute Force Login Attempts:

• What We Found: ProcessWire does slow down login attempts if someone keeps trying the wrong password. But it only blocks based on username, not by tracking where the login attempts come from (like IP addresses).
• Suggestion: It would be safer if ProcessWire blocked login attempts based on IP as well. Also, the system could use a response code like “429 Too Many Requests” to alert attackers that they’re being blocked.

Session Cookie Security:

• What We Tried: Session cookies (used to keep users logged in) seem secure, but we couldn’t fully test if they were safe from all advanced attacks.
• Future Testing: We’d need more tools and knowledge to explore if these session cookies could ever be forged to trick the system.

File Access Control:

• What We Saw: Files from unpublished pages could still be accessed if someone knew the file path, which could leak private information.
• Fix: ProcessWire should make a certain setting ($config->pagefileSecure) enabled by default to restrict file access based on page permissions. This way, only authorized users can see those files.

HTTPS (Secure Connection) Enforcement:

• Current Setup: ProcessWire requires HTTPS (secure connection) settings to be turned on manually in the .htaccess file, which may not be done by every user.
• Recommendation: It would be better if HTTPS were enabled by default, so all sites are secure right from the start.

Improving Activity Logs:

• Missing Logs: Some important activities like content changes and role updates aren’t logged by default.
• Suggestion: ProcessWire should add logs for these actions. This way, any unusual activity can be tracked and traced back to the user who made the changes.

Password Rules:

• Issue: Passwords set through the API (another way to interact with the system) might not meet the same security rules as those set in the admin panel.
• Improvement: ProcessWire should require all passwords to meet the same standard, ideally making them at least 12 characters long and easier for users to remember.

Overall, ProcessWire has a strong security foundation, but these adjustments could make it even safer. This experience showed us the value of secure default settings, especially for users who might not make these changes on their own.

[teppo]

First of all, you’ve got some solid suggestions here. Thanks for sharing.

Just a couple of notes:

14 hours ago, omshah said:

Suggestion: It would be safer if ProcessWire blocked login attempts based on IP as well. Also, the system could use a response code like “429 Too Many Requests” to alert attackers that they’re being blocked.

Agreed, IP based blocking should be enabled by default. I did notice that you said this was tested with the default settings, but it should be noted that IP blocking is an option that can be easily enabled.

I do not agree with your second suggestion, though. In fact the system should preferably try to make blocked requests look exactly the same (and take exactly the same time) as those that were not blocked. Strictly from security point of view, that is; compromises often have to be made to meet user expectations.

14 hours ago, omshah said:

Recommendation: It would be better if HTTPS were enabled by default, so all sites are secure right from the start.

Though I definitely appreciate the sentiment, this is not really realistic requirement, in my opinion. HTTPS is always a good idea and available in most cases, but this could become an issue e.g. considering development environments. As such, I feel that current default makes a lot of sense, all things considered.

And again, thanks for sharing your findings!

[kongondo]

14 hours ago, omshah said:

For our KIT325 Cybersecurity Project, we recently checked the security of ProcessWire CMS,

Hello. Thanks for your work and report. Welcome to the forums.

[brodiefarrelloates]

Thanks for posting @omshah. I was also a part of this assessment group, in my day job I work on antarctica.gov.au, and several other large Processwire sites.

18 hours ago, teppo said:

Agreed, IP based blocking should be enabled by default. I did notice that you said this was tested with the default settings, but it should be noted that IP blocking is an option that can be easily enabled.

What are the impacts of having it enabled by default? Is it just extra overhead?

On 10/31/2024 at 2:02 PM, omshah said:

Improving Activity Logs:

• Missing Logs: Some important activities like content changes and role updates aren’t logged by default.
• Suggestion: ProcessWire should add logs for these actions. This way, any unusual activity can be tracked and traced back to the user who made the changes.

Certainly agree that permissions changes should be logged somewhere for accountability purposes. Not sure if it should be a new log, or part of the session log? Maybe different is best.

18 hours ago, teppo said:

I do not agree with your second suggestion, though. In fact the system should preferably try to make blocked requests look exactly the same (and take exactly the same time) as those that were not blocked. Strictly from security point of view, that is; compromises often have to be made to meet user expectations.

Upon reflection, I think you're right here @teppo - I think 429 is best returned for legitimate (authenticated) responses to something like an API to indicate that whilst successful and allowed, the rate limit has been exceeded. It is best to hide the fact any security actions have occurred.

Overall Processwire is so solid, I've used it for over 12 sites now. Everything from small business to large government entities - it's such a blast to work with.

[cwsoft]

4 hours ago, brodiefarrelloates said:

What are the impacts of having it enabled by default? Is it just extra overhead?

https://processwire.com/docs/security/admin/#preventing-dictionary-attacks

For sites with simultaneous users coming from the same shared IP address, throttling by IP address may lock out legitimate users. Had this scenario with a project with about 1.000 frontend user accounts, which could sign in for courses. All get an E-Mail with their login credentials at about the same time. We had about 50-100 users from a big company using a shared IP address. Here some (5-10) of those users where blocked. So I allowed some IP ranges to not lock out legitimated users sharing the same IP address, simply to reduce the support request for my clients site operators.

If this scenario doesn‘t matter for your sites, I would always turn on throttling by IP address.

Edited yesterday at 04:47 PM by cwsoft