Consider changes/updates to insecure plugin design

[Bobsimonoff]

Addition to the intro: Since plugins are, under normal circumstances, accessed only by the LLM, exploitation is typically a result of another vulnerability such as excessive agency or direct or indirect prompt injection. However, plugins are still responsible for protecting themselves since side-channel attacks can still occur.

Possibly updates to Common Examples:

1. A plugin accepts its input parameters in a single text field instead of distinct input parameters that can be validated and sanitized.
2. A plugin accepts raw SQL or programming statements, which are more difficult to validate than distinct parameters.
3. A plugin adheres to inadequate fine grained authorization controls.
4. A plugin blindly trusts that the LLM output, which is the input to the plugin, correctly represents the expected output for the initial prompt.
5. A plugin treats all LLM content as being created entirely by the user and performs any requested actions without requiring additional authorization.

Possiblr changes to attack scenarios

2. A plugin used to retrieve embeddings from a vector store accepts configuration parameters as a connection string without any validation. This allows an attacker to experiment and access other vector stores by changing names or host parameters and exfiltrate embeddings they should not have access to.
3. A plugin accepts SQL WHERE clauses as advanced filters, which are then appended to the filtering SQL. This allows an attacker to stage a SQL attack.
4. An attacker uses indirect prompt injection to exploit an insecure code management plugin that has no input validation and weak access control to transfer repository ownership and lock out the user from their repositories.

[GangGreenTemperTatum]

Temporarily reassigning this to myself as agreed with John for short term cover