Gevoelige informatielek: OAuth2 clientgeheim blootgesteld in admin-instellingen (niet gemaskeerd)

[Evie_Tao]

Probleembeschrijving

Tijdens een beveiligingsbeoordeling van onze aangepaste Discourse-implementatie hebben we een mogelijke openbaarmaking van gevoelige informatie gevonden in de Admin > Instellingen-interface met betrekking tot OAuth2 client secrets.

Details

• Op de admin configuratiepagina worden het OAuth2 client secret (en mogelijk andere gevoelige tokens/sleutels) in platte tekst weergegeven, in plaats van gemaskeerd te zijn (bijv. met sterretjes).

• Beheerders zijn verplicht om het platte secret rechtstreeks in de instellingen in te voeren. Iedereen met toegang tot de admin UI kan het volledige secret zien.

• Als een aanvaller toegang krijgt (zelfs tijdelijk) tot een admin-sessie, kunnen ze gemakkelijk het client secret verkrijgen en gebruiken voor ongeautoriseerde OAuth2-tokenaanvragen of om aanvragen naar externe services te vervalsen.

Beveiligingsimpact

• Blootstelling van secrets in platte tekst in de admin UI verhoogt het risico op het lekken van inloggegevens.

• Het ontbreken van maskering is niet in lijn met beveiligingsbest practices voor het omgaan met secrets.

• De secrets/tokens kunnen worden misbruikt voor privilege-escalatie, impersonatie of verdere aanvallen tegen geïntegreerde services.

Vragen

• Is er een plan om gevoelige velden zoals OAuth2 secrets te maskeren in de admin instellingen UI (bijv. weergeven als ****** met de optie om indien nodig te onthullen)?

• Zijn er aanbevolen benaderingen of plugins om de bescherming van gevoelige inloggegevens in Discourse-implementaties te verbeteren?

• Is dit probleem eerder besproken? Zijn er workarounds beschikbaar tot een officiële oplossing?

Bedankt voor uw aandacht voor deze belangrijke beveiligingskwestie!

[Moin]

Hey @Evie_Tao
You are reporting lots of security concerns. Have you thought about reporting them on HackerOne, as it’s explained in the GitHub repository?

Security Overview · discourse/discourse · GitHub

[supermathie (Michael Brown)]

@Evie_Tao

Is there a plan to mask sensitive fields like OAuth2 secrets in the admin settings UI (e.g., display as ****** with the option to reveal if necessary)?

We don’t consider information disclosure to administrators a problem, but yes it should be marked as sensitive to avoid showing up unnecessariliy, the same as e.g. google_oauth2_client_secret.

This is a simple fix:

FIX: mark oauth2_client_secret as secret

@Evie_Tao

• Administrators are required to directly input the plain secret into the settings. Anyone with access to the admin UI can see the entire secret.
• If an attacker gains access (even temporarily) to an admin session, they could easily obtain the client secret and use it for unauthorized OAuth2 token requests or to forge requests to third-party services.

There’s a tradeoff of secrecy vs. convenience; not allowing the secrets to be unmasked in the UI would only provide an illusion of inaccessibility, there’s other ways for an admin to easily read it from the database.

However, any secrets (any site setting really) can be specified via the environment, then they won’t show up in the admin UI.

(right @pmusaraj?)