nerdexam
ExamsGCIHQuestions#379
GIAC

GCIH · Question #379

GCIH Question #379: Real Exam Question with Answer & Explanation

The correct answer is C: Filter disallowed input characters for each possible encoding scheme at the application server. The data in the log file is html encoded. Attackers may encode the submitted strings using various encoding schemes (ASCII, Hex, Unicode, etc.) to avoid detection. Moreover, the case of letters in HTML code can be mixed (HTML is case insensitive as regards to tag and attribute na

Web Application Attacks & Post-Exploitation

Question

During the identification phase of a potential incident, you examine the logs of a web server, which are full of lines like the one displayed below. During the preparation phase, what measures would you take to mitigate the risk of attacks that produced these logs? 192.168.56.1 - - [08/Aug/2011:09:35:48 -0400] 'GET /?_task=<sCRipT>alert(document.cookie)</sCRipT> HTTP/1.1' 200 5418 '-' 'Googlebot/2.1

Options

  • AUse parameterized stored procedures in the web application that accesses the database
  • BConfigure the file robots.txt of the web server properly to prevent spidering
  • CFilter disallowed input characters for each possible encoding scheme at the application server
  • DApply a timestamp within the variable or create random hashes using a strong algorithm

Explanation

The data in the log file is html encoded. Attackers may encode the submitted strings using various encoding schemes (ASCII, Hex, Unicode, etc.) to avoid detection. Moreover, the case of letters in HTML code can be mixed (HTML is case insensitive as regards to tag and attribute names). Hence, sCRipT and script are the same. The above log decodes to <script>alert(document.cookie)</script>. When the scripts executes, a pop-up dialog box appears displaying the cookie of the victim. This is an XSS attack, which can be prevented by filtering out the offending characters at the web application, taking into account the various encoding This is not an SQL injection attack (there are no keywords such SELECT, UNION, etc., or statements like OR 1=1) and so, the use of parameterized stored procedures wouldn't help in this case. This is not a session hijacking attack either, since there is no evidence of a session ID variable that the attacker attempts to guess or to manipulate in another way and hence, applying a timestamp within the variable or creating random hashes using a proper function, like md5sum wouldn't also help. This is not web spidering, (although the attacker has changed the User-Agent to appear to be GoogleBot) because, in such a case different URLs would be accessed in a very short time (almost simultaneously); thus, modifying the robots.txt file wouldn't prevent such attacks too.

Topics

#XSS prevention#input validation#encoding schemes#web application security

Community Discussion

No community discussion yet for this question.

Full GCIH Practice