Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.Net: Bug: [dotnet] Handlebars plan invocation will html-encode any "unsafe" string without the possibility to control this behavior #9782

Open
kandraos opened this issue Nov 21, 2024 · 0 comments
Labels
bug Something isn't working .NET Issue or Pull requests regarding .NET code triage

Comments

@kandraos
Copy link

Hello SK community!

I’m encountering an issue where JSON strings produced by trusted kernel functions while being executed within a handlebars plan invocation are being unnecessarily HTML-encoded during plan execution.

Please find below a description of the issue I’m facing. This example has been simplified for illustration purposes but represents the real issue well.

I have a kernel that contains the following 3 Kernel Functions:

  • get_json_step1
    o This function takes no inputs and outputs a json string (e.g., {"Name":"John Doe","Age":30} )
  • process_json_step2
    o This function takes in a json string and processes it by appending to it the phrase “has been processed” without any other modifications
  • my_json_workflow
    o This function takes no inputs and uses a pre-defined handlebars plan to call the first 2 functions in order
    o Here is what the plan looks like (simplified):
    - myJSON = get_json_step1
    - output = process_json_step2(myJSON)

I also set up a function filter to examine the results of each step of the workflow. The results are shown below:

Image

By looking at the results, we notice the following:
• The result of step 1 contains the JSON string as we would expect it
• The result of step 2 contains the JSON string, with the unsafe html characters escaped ( “ -> ")
• The result of the workflow contains the JSON string, with the unsafe html characters escaped again (" -> ")

After digging a bit deeper, it seems like when the output of a function gets added to the KernelArguments object associated with the workflow function invocation (that grows as the handlebars plan execution advances), it is automatically encoded.

I’ve come across the following blog post: https://devblogs.microsoft.com/semantic-kernel/protecting-against-prompt-injection-attacks-in-chat-prompts/
This post mentions a way to “Allow dangerously set content” for chat prompts. It seems like this post is the only documentation about unsafe characters that I could find online, and it does not address the specific issue I’m observing here.

While we understand the need to encode unsafe strings, we would like to “allow” certain content to contain unsafe characters. In this example, the JSON string is produced by a “trusted” function, and we do not want it to be encoded. Are there any parameters we can set to prevent this behavior?

I’ve attached a simple example program using C# that illustrates this example. I had to convert the .cs file to .txt to be able to attach it, but this one file should be enough to represent the issue. Please feel free to reach out if you need any more clarification on this issue I’m facing.

Program.txt

Thanks!

@kandraos kandraos added the bug Something isn't working label Nov 21, 2024
@markwallace-microsoft markwallace-microsoft added .NET Issue or Pull requests regarding .NET code triage labels Nov 21, 2024
@github-actions github-actions bot changed the title Bug: [dotnet] Handlebars plan invocation will html-encode any "unsafe" string without the possibility to control this behavior .Net: Bug: [dotnet] Handlebars plan invocation will html-encode any "unsafe" string without the possibility to control this behavior Nov 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working .NET Issue or Pull requests regarding .NET code triage
Projects
None yet
Development

No branches or pull requests

2 participants