Every SY0-701 study group hits the same pileup. SQL injection and command injection. Cross-site scripting and cross-site request forgery. They all involve an attacker typing something nasty into a box, and after a long study night they blur into one question with the letters shuffled. Then the exam hands you a scenario with no acronym in sight and asks which attack you are looking at.
Four memorized definitions do not survive that moment. One question does. Just one. Ask it about any web attack and each one drops into a different box: who trusts whom here, and which way does the malicious thing travel?
SQL injection: the app trusts your input as part of its query
A login form takes your username and pastes it straight into a database query. You type ' OR '1'='1 and the query now reads as "log in if the password is right OR if one equals one." One always equals one. So you are in.
The broken trust is the application treating what you typed as part of its own command instead of as plain data. Everything else about SQLi flows from that. The fix is parameterized queries, also called prepared statements, which send the code and the data down separate channels so your input can never become SQL. Least-privilege database accounts and tight input validation shrink the blast radius. The real answer on the exam is separating code from data.
Command injection: the shell trusts a string the app built from your input
Same shape, different target. A web tool pings a host you name, and behind the scenes it runs ping <your input>. You enter 8.8.8.8; whoami and the server runs two commands: the ping, then whoami. Now you are executing operating-system commands on their box.
Here is the whole distinction. If the attacker ends up talking to a database, it is SQL injection. If they end up talking to the OS shell, it is command injection. That one fork answers most of these questions.
Cross-site scripting: the victim's browser trusts the server's page
Now the target moves from the server to another user. You plant a script somewhere the site will echo back later, like a comment box or a profile name. When the victim loads that page, their browser sees your script arriving from a site it already trusts and runs it. Now your code can read their session cookie, or do whatever that page is allowed to do.
Three flavors show up on the exam. Stored means the script lives in the database and hits everyone who views the page. Reflected means it rides inside a crafted link and fires when the victim clicks. DOM-based means the page's own JavaScript writes untrusted input into the page. Same root every time: the victim's browser trusts content from the server, and the server handed it your script.
Cross-site request forgery: the server trusts the victim's browser
CSRF flips the direction. You do not steal anything from the victim directly. You get their browser to send a request they never meant to send.
The victim is logged into their bank in one tab. They visit your page in another. Your page quietly fires a transfer request at the bank, and the browser attaches the victim's session cookie automatically, because that is what browsers do. The bank sees a valid cookie and honors the request, because from the server side it looks exactly like the real account holder clicking transfer while logged in, which is the whole reason a cookie makes a lousy proof of intent. Nothing was stolen. The victim's own authenticated browser was the weapon.
The pair that trips everyone: XSS vs CSRF
The exam loves these two because the names read like mirror images. In a way they are. XSS abuses the trust the user's browser places in the site, so a script from a trusted origin runs. CSRF abuses the trust the site places in the user's browser, so a request carrying a valid cookie gets honored.
Watch the direction. Trace the arrow. XSS pushes code out to the victim, server to browser. CSRF pushes a forged request back at the server (browser to server) riding credentials that tag along for free. Different trust, opposite direction.
A ten-second decoder for the scenario questions
- Untrusted input landed inside a database query? SQL injection.
- Untrusted input landed in an OS command? Command injection.
- A script ran in some other user's browser? XSS.
- A victim's browser got tricked into making an authenticated request? CSRF.
The mitigations sort just as cleanly. Injection gets fixed by keeping code and data apart, with parameterized queries and safe API calls. XSS gets fixed on output, with context-aware encoding and a Content Security Policy. CSRF gets fixed by proving the request was intentional, with anti-CSRF tokens and SameSite cookies. Once you have named the trust that actually broke in the scenario, the mitigation stops being a separate fact to memorize and turns into the obvious way to keep that same trust from getting abused a second time. Match the mitigation to the trust that broke and you rarely miss. That is the payoff.
Drill it, do not reread it
Reading this once will not stick. Write yourself five scenario stems with no acronyms in them. One per attack. Then force yourself to say the attack and its fix out loud. Then do it under a clock, because the real thing is timed. If you want stems already stripped of the acronyms, the practice bank and the free diagnostic at secplusmastery.com/diagnostic hand you the scenario first and the label second, which is the order the exam uses. The lessons behind all this live at secplusmastery.com.
So drill it. Learn the four by who trusts whom, and the web attack questions stop being a coin flip.
Top comments (0)