Input Validation and Protection against Injection Attacks

When designing systems that interface with MPS, it is important to consider the source of user input as well as the source of system maintained or derived input, that input that is not user supplied. If you are designing an interface that will be directly exposed to end-users such as a Self Care Portal, you must assume that any data entered into the system is suspect and could be malicious. This applies as well to those parameters that are not directly end-user supplied but are pulled from external sources. The most typical example of this would be the preferredDomainController property.

It is important to understand the source of these system maintained values, some questions you may want to ask are:

Input into MPS whether it is user supplied through a form on a Web Site, System maintained or derived from a combination of the two, can be used in a number of different ways within HMC Provisioning Workflows. While there are some protections in place throughout the system and workflows, a developer should assume that any piece of input could be used -- for example:

Any of the cases above could expose an application or system to security risks if the input is not properly protected. At a minimum this may entail properly encoding URLs and strings. More extreme measures may include storing and comparing against whitelisted values or partial string matches to ensure validity.

Effective Data Validation for MPS

Effective data validation for MPS is similar to data validation for any web exposed application. Developers writing against MPS should follow the data validation best practices outlined in the following topic: How To: Protect From Injection Attacks in ASP.NET.

In addition to these, there are some general MPS Data Validation best practices that should be considered.