Securing PowerShell: How to Stop Prompt Injection Attacks, Part 2Securing PowerShell: How to Stop Prompt Injection Attacks, Part 2Securing PowerShell: How to Stop Prompt Injection Attacks, Part 2
The second part of this five-part series on stopping prompt injection attacks defines what a prompt injection attack is and provides a simple example of such an attack.
[Editor's Note: This is Part 2 of our comprehensive five-part series examining strategies to prevent prompt injection attacks. For readers interested in the complete context, we recommend reviewing Parts 1 , 3, 4, and 5 .]
In the first part of this article series , I walked you through the process of building a database and a simple PowerShell script that is designed to query that database.
In spite of this script's simplicity, however, my script is extremely vulnerable to attack. There are any number of ways that an attacker could potentially exploit the script's simplicity and trick the script into giving up data that it shouldn't. Worse yet, these types of prompt injection attacks could be used to modify or even delete existing data. So let's discuss how a prompt injection attack works .
What Is a Prompt Injection Attack?
Before getting started, let's look at what a prompt injection attack is. At its simplest, a prompt injection attack occurs when a user enters executable code (in this case, SQL commands ) into an input field that is expecting something else entirely. In the case of the PowerShell script that I showed you in Part 1, for example, the script is expecting the user to enter a username. However, there is nothing within the script that prevents a user from typing something other than a username. The prompt injection attack techniques that I will be showing you involve a user typing SQL commands rather than entering a username.
Related:Why Can’t PowerShell Session Access My Network Volumes?
These types of attacks are used in the real world, and they are especially effective when used against scripts such as ours that dynamically construct SQL queries.
Example of a Prompt Injection Attack
With that said, let's take a look at a really simple example of a prompt injection attack. As you may recall, our sample script prompts the user to enter a username, and then it returns that user's email address. However, you can alter the script's behavior by entering SQL code instead of entering a username. For this first example, let's enter:
' OR 1=1 --
In order to see why this particular string is effective, it is necessary to revisit the SQL query that is coded into the script. That query is:
Select Email From Users WHERE Username= '
When you append the attack string, the query becomes:
Select Email From Users WHERE Username= '' OR 1=1 --.
This effectively tells SQL that you want to see all of the results for blank usernames or for any situation in which 1=1. Since 1 always equals 1, the condition is always true. The end result is that the script displays all of the email addresses contained within the database. You can see the script's behavior in Figure 1.
Related:PowerShell Arrays: How To Build, Manipulate, and Manage Them
PowerShell script
Figure 1. The attack caused the script to display all of the email addresses stored within the database.
That's a good start, but gaining access to a list of email addresses is of limited usefulness. So how about we try to use a prompt injection attack to get access to something more useful, such as usernames and passwords?
In this particular case, all of my usernames and passwords are stored in clear text, even though that probably wouldn't be the case in real life. That's OK, though, because my purpose in writing this article series isn't to show you how to gain access to a password, but rather to demonstrate how prompt injection attacks can be used to trick a script into giving up information that it would not normally reveal.
With that in mind, let's set a couple of ground rules for this particular experiment. First, let's pretend that the attacker does not have access to the PowerShell script's source code. This means that making modifications to the source code is not going to be an option for our would-be attacker. It also means that the attacker cannot study the source code to gain insight into the database's structure or into the script's internal workings. Even though I wrote the PowerShell script myself, I am going to pretend that I do not know anything about it.
Related:10 Most Popular PowerShell Tips and Tricks of 2024
A second ground rule for this particular experiment will be that manually entering PowerShell commands at the command prompt will be off limits. While it is true that an attacker would have no such restriction, I want to focus on demonstrating the effectiveness of a prompt injection attack, not circumventing a script's defenses by manually entering commands as a way of going around the script.
Finally, it probably goes without saying, but I am also setting a ground rule stating that the attacker does not have direct access to the SQL Server database. In other words, the attacker cannot open the SQL Server Management Studio and use it to explore the database. I am also going to assume that the attacker has absolutely no knowledge of the database's name, structure, or contents. However, for the purposes of this article series, I am going to pretend that the attacker has at least figured out (or perhaps, guessed) that the database is hosted on SQL Server as opposed to some other platform.
We will pick it up there in Part 3 by using prompt injection attacks to explore the database and ultimately to gain access to the data stored within it.
About the Author
Technology Analyst
Brien Posey is a bestselling technology author, a speaker, and a 20X Microsoft MVP. In addition to his ongoing work in IT, Posey has spent the last several years training as a commercial astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space.
You May Also Like
ITPro Today's 2025 IT Priorities Report
Aug 8, 2025|2 Min ReadEdge Computing Trends: Adoption, Challenges, and Future Outlook
Jul 15, 2025|2 Min ReadITPro Today’s 2024 State of DevOps Report
Dec 16, 2024|2 Min ReadBCDR Basics: A Quick Reference Guide for Business Continuity & Disaster Recovery
Oct 10, 2024|1 Min Read
Recent What Is
Enterprise Connect 2026 – All In on What’s Next