[WP][SR] Dedicated "Privacy & security" section under "Configuration"

[klonos]

I would like us to have a dedicated "Security" admin page and a respective Admin menu item in order to:

• show that we take security seriously
• allow site admins to perform security-related tasks in one single place
• provide a "home" for security-related contrib modules

Ideas for this page include:

• settings for blocking users (failed login attempts, bots etc.) - #1878
• provide a default security.txt file ((https://www.drupal.org/project/securitytxt)), and an easy way to edit that info via the UI. The default, out of the box text should point to contact details for reporting security issues in b.org, but site owners should be able to change that if required by their organization (same as we allow them to edit the maintenance mode message)
• settings for protecting forms from spam (expose honeypot settings etc.) - #1169
• settings for the trusted_host_patterns variable - #2568
• settings for the x_frame_options variable - #4080
• checkbox to ignore outdated php warning - #3490
• link to our https://backdropcms.org/security page
• database (SSL) connection status - #4945
• enable/disable FLoC - #5103
• a setting to enable better security/privacy on login/password reset forms - #4696
• a setting to use 404s instead of 403s when trying to access user pages without the proper permission #5802

Other ideas:

• A "Security overview" block for the dashboard (#495)
• https://www.drupal.org/project/security_review
• https://backdropcms.org/project/remove_generator (only 3 lines of code really)
• any settings that may be required for #3270
• warning when anonymous users can create accounts (#574)
• expose the image_style_flood_limit setting introduced in https://github.com/backdrop/backdrop-issues/issues/34 / https://github.com/backdrop/backdrop/pull/635
• ???

[jenlampton]

Interesting. I've also been thinking that I wanted to move "Development" up to the top level... how would you feel about "Development" > "Security" (or admin/development/security) for the security page? It would be second level but still easy to find.

[klonos]

I've also been thinking that I wanted to move "Development" up to the top level

Yeah, this is already done if you install the devel module, resulting in 2 "Development" menu items, a top-level one, and one under "Configuration" (https://github.com/backdrop-contrib/devel/issues/43). I think that we should merge these, and I agree that we should move "Development" to become top level.

how would you feel about "Development" > "Security"

Hmm, I would actually prefer "Security" under "Configuration", because that does not seem to be an exclusively dev-related topic to me.

In fact, I would also rather that "Performance" was moved out of "Development", and then have both "Security" and "Performance" live under "Configuration" > "System"

So, to sum up:

• Development (becomes top-level: #3652)
• Configuration
  • System
  • Security (new menu item - this issue here)
  • Performance (moved out of "Development" - separate issue)
  • Updates (#3388)

[jenlampton]

and then have both "Security" and "Performance" live under "Configuration" > "System"

What's the value of System here? ...although, it does provide context. "System security" and "System updates" both seem logical.

and then have both "Security" and "Performance" ...

Hold on, Performance? Disabling caching is definitely a developer-only task. Why move that out of the devel section?

[jenlampton]

What's the value of System here?

I just want to add here what I mentioned in the issue about the updates link ...

I object to using system because that's sort of a cop-out "other" category, where we put things that we can't figure out where else to put. I never know what's in there, and I never look there for anything important.

If we do start to put things there that aren't "Other" things, we should really define what System means first so we know if we are using it correctly :)

[klonos]

Fair enough, how about this then?:

• Development (becomes top-level: #3652)
• Configuration
  • ...
  • Security (new menu item - this issue here)
  • System (retains its current "other" or "miscellaneous" functionality)
  • Updates (#3388)
  • ...

[jenlampton]

Better!

On Sat, Jun 15, 2019, 3:22 PM Gregory Netsas notifications@github.com wrote:

Fair enough, how about this then?:

• Development (becomes top-level: #3652 https://github.com/backdrop/backdrop-issues/issues/3652)
• Configuration
  • ...
  • Security (new menu item - this issue here)
  • System
  • Updates (#3388 https://github.com/backdrop/backdrop-issues/issues/3388)
  • ...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/backdrop/backdrop-issues/issues/3624?email_source=notifications&email_token=AADBER5FVXZG3OQ3FF3UJNLP2VTTDA5CNFSM4HBSMXJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXZBF3A#issuecomment-502403820, or mute the thread https://github.com/notifications/unsubscribe-auth/AADBER4M2F7C2JTOIUEM6EDP2VTTDANCNFSM4HBSMXJA .

[klonos]

I have added https://www.drupal.org/project/security_review to the list of ideas:

[klonos]

Here's what's in the recent v5.4 of WordPress (I really like how each item is denoted as either a security or a performance issue):

Passing checks are collapsed by default, to reduce clutter on that page. Here's a screenshot of what other checks are included, with some of them expanded:

[jenlampton]

Interesting, I wonder if we could add the same kind of categorization to items on our status report. I suspect we may have way too many categories :)

I've been using Security Review on a handful of my sites, and I'm actually finding it not that helpful. There are a few checks that throw false positives, whereas similar checks we already have in core are (mostly around file permissions) are more accurate. I do think there are a few good ones though, and we should consider incorporating those into our status report.

[yorkshire-pudding]

I agree with this proposal. Security review can be quite helpful, though I think there is one test that is particularly unhelpful.

Other modules prevent username and/or password enumeration which might be worth mentioning.

[stpaultim]

@alanmels just opened a similar issue and closed it, I think it because of this existing issue.

This seems like a good idea and I think Alan's suggestion is consistent with what was being discussed here. I think we just need a PR to get this issue moving again.

One thing seems a bit tricky to me: the security / anti-spam modules in the example are contrib. How can we evaluate in core, which modules belong to that section? For example: do all anti-spam modules belong there? So we might also consider this a contrib candidate?

Isn't the point here to create a section where security / anti-spam modules can list themselves? I think that core can provide the section, but each modules decides on it's own where to put it's menu link. Don't we just want to provide a good place for them to go. Once a section exists, we can submit PR's to obvious candidates for this section to move their menu link.

I would just like to clarify if this issue is about a "Security Page" or a "Security Section" under Configuration - as the title suggests? These are two different ideas.

[alanmels]

I believe this issue should be revived and a new Security section must be implemented.

[indigoxela]

So maybe the first things to figure out here:

1. What should go to that section (core settings, modules...)
2. How to get contrib/custom modules in there (hook or create dedicated "tags" for info files?)
3. What it should look like (informative, but not overwhelming...)
4. Maybe clearly define the target audience, so we can properly address them

^^ That's random order and probably incomplete. :wink:

[alanmels]

@indigoxela look at this line https://github.com/backdrop-contrib/protected_forms/blob/72a1100447dda575c5326b1ba5c2a5366482888f/protected_forms.module#L25 When implementing the hook_meu() contributed modules have to choose between different sections, so in this particular case the Content section was chosen due to absence of more appropriate section.

So there is no issue here about doing anything additional. Both core or contributed modules would be able to place configuration links in the section if they are about security.

It would look like the screenshot on https://github.com/backdrop/backdrop-issues/issues/5639

[indigoxela]

... hook_menu ...

Ah, now I get it. But wouldn't that force all contrib modules that should show up in that section to change their hook_menu implementation?

Maybe the path was chosen by intention. For instance under admin/config/content for content authoring related modules or admin/config/people for user account related modules? Stuffing them all under the same path (also admin menu) could be very confusing.

[alanmels]

Maybe the path was chosen by intention. For instance under admin/config/content for content authoring related modules or admin/config/people for user account related modules? Stuffing them all under the same path (also admin menu) could be very confusing.

Right, but where modules like Protected Forms or Honeypot should go if they are not exactly about content authoring? They are about security, spam-prevention.

[alanmels]

Not every module implements hook_menu, but those who do could list their configuration links under the Security section. And here are some of the modules which could be listed in that section:

https://backdropcms.org/project/captcha https://backdropcms.org/project/antibot https://backdropcms.org/project/riddler https://backdropcms.org/project/ip_anon https://backdropcms.org/project/honeypot https://backdropcms.org/project/rename_admin_paths https://backdropcms.org/project/spambot https://backdropcms.org/project/previous_login https://backdropcms.org/project/hsts https://backdropcms.org/project/security_review https://backdropcms.org/project/securitytxt

[alanmels]

And I wonder why there is separate Search section, when Search settings link could be placed in the System section? Are there also lots of Web services modules to have their own section? More than the modules about security, protection and spam-fighting? I don't think so. You see, we inherited the structure of the Configuration page (admin/config) from Drupal and never updated it according to new trends, needs. Imo, security and protection modules are more important to have their own section than Web Services with a single RSS publishing link there.

[ghost]

I'd love to see a new 'Privacy and Security' section under Configuration:

I think the blocker is not having anything to put there yet... If/when one of the linked features in the OP gets merged, we can add this section and move its UI there. But until then, there's not much point having a blank section of the menu.

[klonos]

I think the blocker is not having anything to put there yet ...

There are some things from the OP that we can put there + I'm hoping that #4696 will get merged soon (it is a Backdrop adaptation of a D7 backport of a feature that was introduced in D9.2.x).

[klonos]

Saw this (from the Samsung One UI page) and liked the visual/aesthetics:

Putting it here for inspiration.

[ghost]

and licked the visual/aesthetics

How'd they taste? :smile:

[klonos]

🤣 🤣 🤣

Surprised you didn't mention the "fro me the" ...I have my days with typing, don't I?

[yorkshire-pudding]

Oh how issue threads grow. I haven't read everything yet. But, what are the pros and cons of honeypot over antibot module? Should this be a separate issue or a forum question?

@izmeez - forum really; that's not a question about core and not the focus of this issue