chores/add authorization

[andreasisnes]

Verification

• Your code builds clean without any errors or warnings
• Manual testing done (required)
• Relevant automated test added (if you find this hard, leave it and we'll help out)
• All tests run green

Documentation

• User documentation is updated with a separate linked PR in altinn-studio-docs. (if applicable)

To fix the problem, we need to ensure that the decision to call AuthorizeJsonRequest or AuthorizeXmlRequest is not based solely on user-controlled data. Instead, we should validate the ContentType header securely before making the decision. One way to achieve this is to use a whitelist of allowed content types and ensure that the content type is valid before proceeding.

We will add a method to validate the content type and use this method in the Post action to decide which authorization method to call. This ensures that only valid content types are processed, reducing the risk of user-controlled bypass.

To fix the problem, we need to ensure that the user-provided XML content is validated against a known schema before processing it. This can be achieved by using XmlReaderSettings with the appropriate validation settings.

1. Create an instance of XmlReaderSettings.
2. Set the ValidationType to Schema.
3. Add the known schema to the XmlSchemaSet of the XmlReaderSettings.
4. Use the configured XmlReaderSettings when creating the XmlReader.

To fix the problem, we need to ensure that the userId parameter is validated against the authenticated user's ID before performing any sensitive actions. This can be done by moving the validation of userId before the condition userId == 0 || partyId == 0. This way, we ensure that the userId is properly authenticated before proceeding with any further checks.

To fix the problem, we need to ensure that the validation logic is not bypassed based on user-controlled input. Instead of checking if userId is zero, we should validate the userId against the authenticated user's ID at the beginning of the method. This way, we can ensure that the user is authorized to perform the action without relying on user-controlled values.

1. Remove the check if (userId == 0 || partyId == 0) and replace it with a validation against the authenticated user's ID.
2. Ensure that the method proceeds with the validation logic only if the userId matches the authenticated user's ID.

To fix this issue, we need to ensure that the validation logic is not bypassed based on user-controlled data. Instead of returning NotFound when partyId is 0, we should handle this case more securely. One way to do this is to validate the partyId before proceeding with the rest of the logic and ensure that it is a valid, non-zero value.

We will:

1. Add a method to validate the partyId and ensure it is a valid, non-zero value.
2. Use this method to validate the partyId before proceeding with the rest of the logic in the ValidateSelectedParty method.

To fix the problem, we need to ensure that the XML data is validated against a known schema before processing it. This involves creating an XmlReaderSettings instance with the ValidationType set to Schema and specifying the schema to validate against. We also need to ensure that the ValidationFlags do not include ProcessInlineSchema or ProcessSchemaLocation to prevent users from providing their own schemas.

Steps to fix:

1. Create an XmlReaderSettings instance.
2. Set the ValidationType to Schema.
3. Add the known schema to the Schemas property of the XmlReaderSettings instance.
4. Ensure that ValidationFlags do not include ProcessInlineSchema or ProcessSchemaLocation.
5. Use this XmlReaderSettings instance when creating the XmlReader.

To fix the problem, we need to sanitize the rule object before logging it. Since the log entries are plain text, we should remove any new line characters from the rule object to prevent log forging. This can be done using the String.Replace method or a similar approach.

The best way to fix the problem without changing existing functionality is to sanitize the rule object right before it is logged. We will replace new line characters in the rule object with an empty string to ensure that no new lines are introduced into the log.

To fix the problem, we need to ensure that the XML data is validated against a known schema before it is processed. This involves creating an instance of XmlReaderSettings with the appropriate validation settings and using it when creating the XmlReader.

1. Create an instance of XmlReaderSettings.
2. Set the ValidationType property to Schema.
3. Add the known schema to the Schemas property of the XmlReaderSettings instance.
4. Use the XmlReaderSettings instance when creating the XmlReader.

To fix the problem, we need to validate the XML data against a known schema using XmlReaderSettings. This involves:

1. Creating an instance of XmlReaderSettings.
2. Setting the ValidationType to Schema.
3. Adding the known schema to the Schemas property of XmlReaderSettings.
4. Using this XmlReaderSettings instance when creating the XmlReader.

We will modify the ParsePolicy method to include these changes.