Domain 2 questions about application vulnerabilities have a shape that catches people out. The stem describes something that happened, and four vulnerability names sit underneath it. Every one of those names is a real thing that really exists, so none of them are wrong in the general sense.
Knowing what SQL injection is will not get you through the question, because what the question wants is for you to look at a described behavior and put the right name on it. Definitions do not survive that. You can recite the definition of cross-site scripting word for word, sit down in front of a stem that never once uses the word script, and have no idea which of the four names in front of you is the one they mean.
The detail that decides it is almost always the same one.
Where does the untrusted input end up?
Professor Messer describes an injection attack as one where "an attacker can easily add additional malicious code to input that is going to a server or a client device". That is the family. The specific name depends on where the input lands.
SQL injection: the input lands inside a database query. The stem will mention a login form or a search box or a URL parameter, and then something the application should never have returned. Whole tables coming back. A login that succeeded without a password.
Cross-site scripting: the input lands in somebody else's browser. Messer puts the mechanism plainly, saying that XSS "takes advantage of the trust that the browser has for different websites". The victim in an XSS stem is a user rather than the server. Watch for that. If the damage happens to a person who visited a page, you are looking at XSS even when the word script is absent.
Buffer overflow: the input lands in memory. Messer again, "you're adding information into a particular area of memory reserved for a variable, but you're putting more information than that variable can hold". The tell in a stem is a size or a length. A field that accepted more than it should have. A crash. An application that suddenly started running something nobody asked it to run.
Race condition: nothing lands anywhere. There is no payload of any kind in a race condition stem, no crafted string and no oversized field and no malicious link, which is exactly why so many people read straight past it.
Reflected or stored? That one is a question about the link
XSS splits two ways and Security+ does ask which one. The split turns on where the payload was sitting before it ran, and severity has nothing to do with it.
Non-persistent XSS is also called reflected, and it arrives inside the request. Messer describes a site "configured in a way that would allow people to run scripts inside of these user input blocks". A stem that hands you a crafted link over email is the reflected kind, and it works one victim at a time.
Persistent XSS is the stored kind, and it was saved on the site before anybody visited. Messer's example is an attacker who posts a message to a social media site with the payload inside it, so the payload now sits on the site waiting. A stem where every visitor to a page gets hit, with no link anywhere in the story, is stored.
One clicked link, one victim. One saved post, everybody who loads the page.
A race condition does not look like an attack
This is the one that gets skipped. Messer defines it as "when two events happen at nearly the same time with an application, and the application doesn't take into account that these two conditions may be operating simultaneously".
Time-of-check to time-of-use is the version the objectives name. The application checks a value and then uses it. Something changes in the gap. Messer's worked example is a bank transfer where deposits post immediately and withdrawals do not, so a balance gets read before it was updated and an account ends up showing 50 dollars that is not really there.
Where is the attack in that? Both operations were legitimate. No input was malformed. The flaw is the gap.
So the trigger is timing. Two things happening at once, or a value read before it was written.
The wrong answers are controls for a different question
Once you have named the vulnerability, the remediation half of the question usually offers you four real controls.
Input validation is the answer for injection and for XSS, and it does nothing at all for a race condition. Locking, or making the check and the use one atomic operation, is what answers the race. Bounds checking and memory-safe languages answer the overflow.
Then there is the option that shows up everywhere. Patch the application, or apply the latest update. That option is never false, though it is almost never the control being tested, because the question described one specific weakness and wants the control for it.
The drill that fixes this
Take a batch of Domain 2 questions and cover the answer options with your hand, then read the stem and write the vulnerability name from the stem alone.
When you cannot, ask the two questions in order. Where did the input go, and who got hurt? It went to a database or a browser or into memory. If it went nowhere at all, you have a race condition.
If you want stems to run this on, the free diagnostic at secplusmastery.com/diagnostic will show you where Domain 2 sits for you, and the full question set at secplusmastery.com is built around scenarios instead of definitions.
Try it on ten questions tonight and count how many you name right.
Top comments (0)