#auth

### Description Under OIDC authentication mode, there is a redirect_url parameter exposed in the URL which is used to redirect the current user to the defined location after the successful OIDC login, This redirect_url can be an ambiguous URL and can be used to embed a phishing URL. For example: if a user clicks the URL with a malicious redirect_url: ``` https://<harbor_hostnmae>/c/oidc/login?redirect_url=https://<redirect_domain> ``` It might redirect the current user without their knowledge to a malicious site, posing a potential risk. To avoid this issue, the redirect_url should be checked if it is a local path when reading it from the original request URL. ``` //src/core/controllers/oidc.go ... redirectURL := oc.Ctx.Request.URL.Query().Get("redirect_url") if !utils.IsLocalPath(redirectURL) { log.Errorf("invalid redirect url: %v", redirectURL) oc.SendBadRequestError(fmt.Errorf("cannot redirect to other site")) return } if err := oc.SetSession(redirectURLKey, redirectURL...

Users registering via the `user:register_form` tag will have their password confirmation stored in plain text in their user file. ### Impact This only affects sites matching **all** of the following conditions: - Running Statamic versions between 5.3.0 and 5.6.1. (This version range represents only one calendar week) - Using the `user:register_form` tag. - Using file-based user accounts. (Does not affect users stored in a database.) - Has users that have registered during that time period. (Existing users are not affected.) The password is only visible to users that have access to read user yaml files, typically developers of the application itself. ### Patches The issue has been patched in 5.6.2, however any users registered during that time period and using the affected version range will still have the the `password_confirmation` value in their yaml files. We recommend that affected users have their password reset. The following query can be entered into `php artisan tinker` and...

Yii2 supports attaching Behaviors to Components by setting properties having the format `'as <behaviour-name>'`. Internally this is done using the `__set()` magic method. If the value passed to this method is not an instance of the `Behavior` class, a new object is instantiated using `Yii::createObject($value)`. However, there is no validation check that verifies that `$value` is a valid `Behavior` class name or configuration. An attacker that can control the content of the $value variable can then instantiate arbitrary classes, passing parameters to their constructors and then invoking setter methods. ### Impact With some effort malicious code can be injected executed which might be anything ranging from deleting files to dropping database tables ### Patches Not yet patched. ### Workarounds No Work around available ### References Reported [Here](https://huntr.com/bounties/4fbdd965-02b6-42e4-b57b-f98f93415b8f?token=3bcfc5266870680af19a26170b8dbf3750e3b593ce192da8eaa6a03f96b99b52c4...

### Impact Sentry's Slack integration incorrectly records the incoming request body in logs. This request data can contain sensitive information, including the [deprecated Slack verification token](https://api.slack.com/authentication/verifying-requests-from-slack#deprecation). With this verification token, it is possible under specific configurations, an attacker can forge requests and act as the Slack integration. The request body is leaked in log entries matching `event == "slack.*" && name == "sentry.integrations.slack" && request_data == *`. The deprecated slack verification token, will be found in the `request_data.token` key. Example event: ```json { "name": "sentry.integrations.slack", "level": "info", "event": "slack.event.message", # This could be any of the `slack.*` events "request_data": { # Other keys are omitted for brevity "token": "<MyDeprecatedSlackVerificationToken>", } } ``` ### Patches - **SaaS users** do not need to take any a...

The Fides webserver has a number of endpoints that retrieve `ConnectionConfiguration` records and their associated `secrets` which _can_ contain sensitive data (e.g. passwords, private keys, etc.). These `secrets` are stored encrypted at rest (in the application database), and the associated endpoints are not meant to expose that sensitive data in plaintext to API clients, as it could be compromising. Fides's developers have available to them a Pydantic field-attribute (`sensitive`) that they can annotate as `True` to indicate that a given secret field should not be exposed via the API. The application has an internal function that uses `sensitive` annotations to mask the sensitive fields with a `"**********"` placeholder value. This vulnerability is due to a bug in that function, which prevented `sensitive` API model fields that were _nested_ below the root-level of a `secrets` object from being masked appropriately. Only the `BigQuery` connection configuration secrets meets these ...

Live Nation has confirmed what everyone has been speculating on for the last week: Ticketmaster has suffered a data breach.

Data breaches at Ticketmaster and financial services company Santander have been linked to attacks against cloud provider Snowflake. Researchers fear more breaches will soon be uncovered.

Plus: A whistleblower claims the Biden administration falsified a report on Gaza, “Operation Endgame” disrupts the botnet ecosystem, and more.

Artificial Intelligence (AI) company Hugging Face on Friday disclosed that it detected unauthorized access to its Spaces platform earlier this week. "We have suspicions that a subset of Spaces’ secrets could have been accessed without authorization," it said in an advisory. Spaces offers a way for users to create, host, and share AI and machine learning (ML) applications. It also functions as a

In a shared hosting environment that has been misconfigured to allow access to other users' content, a Moodle user with both access to restore workshop modules and direct access to the web server outside of the Moodle webroot could execute a local file include.