Web Input - Securing Data, Hybrid Approach

Web Input - Securing Data, Hybrid Approach

Semi-automated Preventive Method

In this installment, I will cite an example of automated email code designed for another purpose. Nonetheless, I see it is a critical step to confirm the validity of the form's input. Moreover, unless and until I have received the expected human confirmation, that input is left in limbo [1.]. This is another means to prevent spurious, but uncaught data inputs. Thus, this limited human energy expenditure is a high return investment.

I know this method will not stop attacks, however, it increases your odds of recognizing trash inputs. I further suggest a few added twists to make it more difficult for an outsider to return a bogus confirmation. Nonetheless, I advise you to expect these too might be bypassed. I stress, do not under estimate your adversary. Again use all the methods available and hope it suffices to convince intruders to seek easier venues.

New Rules

I intend to focus on this one issue, human confirmation. If I even attempt to express my misgivings, I get mired in ineffective paranoia. Yes, I can see the adversary performing end runs, however, this prescribed hybrid approach requires a flexible opponent, who has access to additional information. Train your users and there is hope (but no certainty).

This article should be short and concise. I can do that by placing focus on one process and by citing similar email code design rather than explicitly repeating it again.

Input Form Code

Below is some of the code shown in the graphic I used in two previous articles [2.], it contains html tags containing the form and some lead in text. I draw your attention to the starting of the form (with its tag) the first few data input with their corresponding labels along with some specifications on each input field. Nonetheless, the most attention here should be paid to the submit button, which is not in the graphic. Moreover, the (submit) button that fires the sending the data to the server and calling the validation code. Here is the abbreviated view just showing part of the form content and the html code near the form, per se:

        <div id="forms-block">
           <h2 id="prod-news">New Article Entry:</h2>

	      <h3>Fill in all empty fields with the correct data, <br />
	        article will then be listed on the Product News front page <br />
		and the full article will be linked for reading.  Take care.</h3>

	      <form method=POST action="http://example.com/[forms path]/test-data.php">

	         <p><label for="pub_date">Date: </label> 
		       <input type="text" name="pub_date" value="October 18, 2007" /> 
		                  
		    <label for="author_name">Author:  </label> 
		       <input type="text" name="author_name" value="" length=30 maxlegth=60 />/p>

	         <p><label for="title">Title: </label> 
		       <input type="text" name="title" value="" length=200 maxlength=512 size=90 /></p>

		 // other inputs and descriptive text.

		 // Adding a submit button, that was missing from the form.

		 <h3><input type="submit" value="Put on Site"></h3>

	      </form>  

As I mentioned above, once the submit button is hit the processing is initiated. The "action" attribute in the html opening form tag either is connected to the validation code or is itself that code that executes on the server. We examine some of our options below.

Decision Point

The question is, how much validation is performed before sending a confirmation request. My form was built for one individual, hence, I probably would have only tested the author's name for an exact match. However, the larger the set of users, the greater your problems. Therefore, I would advise running as many quick tests for bogus input to minimize seeming to be badgering your users.

If it were only so simple, those with a sizable set of potential users must expect some to be careless, hence, some thought must be expended to deal with marginal cases. Consider partitioning those too quick to share their passwords or operational details to be under a separate set of rules. If this represents a small subset of your users without excessive political clout, I would suggest confirming all input attributed to them. Press for explicit, documented verification for this subgroup. Good luck with that.

Whatever degree of testing you intend to perform, once there is no obvious spurious data was proffered you need to initiate the confirmation routine. As I mentioned, this is what would have sufficed for me, i.e. a exact match of the author's name:

   $author = trim($_POST["author_name"]);

   $is_matched = strcmp($field_value, $author);
   // Look at php manual.
   if ($is_match == 0) {
      // Build confirmation request email

      &to      = [author's-neme]@[IPS-Mail];
      &subject = "Please confirm you submitted the content, as detailed.";
      &message = // see notes and link below

   } else {
      // Inform webmaster of attempted bogus entry

      &to      = webmaster@example.com;
      &subject = "Attack attempt, please examine.";
      &message = // see notes and link below
   }

   // run actual email here from standard function or
   // explicit code, see article link in the first
   // paragraph for an explanation of the $header role.

   mail($to, $subject, $message, $header);   

Please use the link mentioned above to see how an email is constructed and sent automatically with code, thus, allowing me to avoid repeating it. Here is a more detailed explanation than I provide for building the email headers. One caveat, the code is Window's centric [3.], i.e. you need to remove the "r" (carriage returns) for Linux / Unix server code.

Building the Email Content

The message I would build would be fairly concise to the presumed author, citing no more than the title and the automatically generated time stamp. The date / time the data was is generated programmatically:

  $_date = date("M j, Y, g:i a"); 
  //  Jun 21, 2008, 10:17 pm (formatted actual date and time) 

which is now inserted into the message:

  $message  = "Please confirm promptly this is your submissionn";
  $message .= "Titled: ". trim($_POST["title"]). n";
  $message .= "Submitted: ".$_date."n";
  $message .= "Respond to Reply-To addressn";
  $message .= "Thank, Auto Editornn"
  $message .= "Email sent: ". date("F j, Y, g:i a")." Central Time zonenn";   

Be certain to include this line in the email header code:

  $headers .= "Reply-To: editor@example.comn";  

This allows rejection of any replies that are in that in box, with good confidence. In my case a phone call would most likely have been the confirmation method or to my regular email address. Be sneaky, however, all too soon those behind the bots will learn they were being duped. Or more likely, someone will be too free in describing the validation process. I suggest having a backup plan.

I think a balance has to be struck, i.e. if the volume becomes too heavy the email notices have to be dropped entirely or focused on picking out the most dangerous. The basic idea is to know the enemy and their methods. Yes, I advise applying easy counter measures, however, make notes on breaches that failed due to dumb luck. Even without a solution in hand, remember the techniques, because you may later think or read of an effective counter measure.

Initially, I suggest sending all the data to an email address you watch. Here is what I might have used:

  $message   = "Bogus entry posted in form:nn";
  $message  .= "Date: ".$pub_date."n";
  $message  .= "Author: ".$author."n";
  $message  .= "Title: ".$title."n";
  $message  .= "Keywords: ".$keywords."n";
  $message  .= "File Name: ".$filename."n";
  ...   

At this point be careful. Though I suggested limiting the size of the other two possible entries, it would be better to look at the supposed article content on the server stored in a text file. The same might be true of a summary, however, here is what I would included in my email in place of the holding ellipsis:

  $message  .= "Article Summary: ".$summary."nn";
  $message  .= "Please search for patterns we can counter.";
  $message  .= "Email sent: ". date("F j, Y, g:i a")." Central Time zonenn";   

Now whatever the case an email notification should be sent to the proper parties. It might be a good idea to use the conditional code shown in an article I cited above to confirm or record the email failed [4.]. That is, add this code:

  if ( mail($to,$subject,$message,$headers) ) {
        // write email sent on text file storing author?
     } else {
        // send another email or write to a local file
	// telling of the failure.  Mark with an id code.
     }   

Whatever the character of the notification, if the email was sent the process is in motion. Either the input will be confirmed or another forensic can be run on the attempted breach [5.]. Having kept the discussion focused on the confirmation, my task is nearly complete.

Email Examples

I worried that this seems like an unneeded filler. Well the editor disagrees, hence here are some examples I copied from various locations from my email. Here is what one version of the test message looked like when a menu name is not communicated properly:

  

	        Fig. 1. Menu Name Failure
	    

This error differs from the one above, the menu name is recognized but this time the actual menu listing file is missing:

  

	        Fig. 2. Menu List File Failure
	    

The example below comes from a mockup of a business form and the transmission of that data to the reviewing party. Note that the date time stamp is at the top and the data of interest is formatted on the page for an easy review. Location of the business, business verifiable id and contact data were the critical data that was sought from the form. Here is the email that was generated, showing only the message portion:

  

	        Fig. 3. Business Form Data
	    

I hope that more than suffices to make the email code explicable.

Review

As I stated at the beginning, the focus is simply on notifying the user their supposed input has been posted. Hence, their role is to confirm they added content. Once the confirmation is received in the correct location the effort can be switched to its original intent of revising the content of the appropriate pages. Thus, this installment is complete

What's Next? Unrestrained Paranoia?

Panic? I hope not. However, I have concerns the hybrid method using human confirmation will not suffice in stopping all dubious inputs. Moreover, I see exposure to other means of circumvention by the attackers. Therefore, I intend to review some these concerns next, then I will move to other issues.

Breaching a site's defenses are not the only danger posed by the use of html input forms. A deluge of spam is another nefarious use of bogus inputs. The one I know of dumps links to dubious sites. In this case it is harassment, because the content is not automatically displayed. Nonetheless, it is debilitating on those that have to deal with the flow. I am going to attempt to discuss the problems concisely in an associated series.

Corrections, suggested extension or comments write please check for email address on the site http://bst-softwaredevs.com thanks.

     © Herschel Cohen, All Rights Reserved

____________________________________________________________________

    1.  The content will be retained, but not as the attacker  
        might expect.

    2.  If you need to be reminded: introductory article or the 
        second on the inputs.

    3.  Despite its bent it is concise and I think well done.
         
    4.  Bottom of the page, where the details have to written 
        to a file for later viewing.  The echo command in auto
	mode is inappropriate.