Author: Lisa

Fortify on Demand Remediation – Cookie Security: Overly Broad

Cookies are tied to hostnames and paths. This vulnerability occurs because not every site is its own hostname – when you own all of application.example.com/*, this is basically a false positive. But, if you host your app on a shared URL (e.g. look at www.rushworth.us/lisa and www.rushworth.us/scott and www.rushworth.us/owa … these are three different sites on my home web server. Scott, on is web site, could set a cookie with a path of “/” that uses the same name as a cookie I use on my site – my site would then use the stuff Scott stored through his site. Not such a problem in our scenarios, but a huge problem if you’re talking about a hundred different people’s blogs on some shared domain.

To sort the vulnerability, set the cookie path to something more than /

Fortify on Demand Remediation – LDAP Injection

If you build an LDAP search criterion from user input, it’s possible for the user to inject unexpected content into the search. If I say my username is lisa)(cn=*) or lisa)(|(cn=*) … a filter of (sAMAccountName=$strUserInput) becomes something unexpected.

In php, there’s a filter to escape LDAP search filters – use ldap_escape()

$scriteria=ldap_escape("(&($strUIDAttr=$strUserLogonID))", null, LDAP_ESCAPE_FILTER);

Chicken Loss

Yesterday, one of our Rhode Island Red’s got taken by a dog. I was walking the chickens from their coop into their tractor. Like normal, most of them cannot find the door and walk a loop around the tractor looking for a way in. I get the food sprinkled around the grass and fill up the water bowls while they work out how exactly to get themselves into the thing. I saw a light brown animal out of the corner of my eye behind our large oak tree. My instant thought was “bugger, a baby deer … we’re about to get run over by an upset mommy deer!” — and then this dog streaked over. It didn’t hesitate even when I yelled, it nabbed a chicken, and then it took off into our woods. Now I’ll have to wake Anya up so we have two people herding chickens into the tractor!

Fortify on Demand Remediation – Header Injection: Cookies

Cookie injection vulnerabilities occur when user input is stored into a cookie. It’s possible for malicious input to include newline characters that would be parsed out as new elements in the cookie. As an example, if I send my user ID as “lisa\r\nadmin: true” … I’ve got a cookie that says the userID is lisa and admin is true.

With Fortify on Demand, you cannot just filter out \r and \n characters – Fortify still says the code is vulnerable. You can, however, filter out anything apart from alpha-numeric characters (and, I assume, any oddball character that has a legit reason to be included in the user input):

$strLogonUserID = filter_var(preg_replace(‘/[^a-z\d_]/iu’, ”, $_POST[‘strUID’]), FILTER_SANITIZE_STRING, FILTER_FLAG_STRIP_LOW);

PHP oci_bind_by_name Caveat (a.k.a. a reminder to read the documentation)

This is readily apparent when you actually read the documentation for oci_bind_by_name … but, if you quickly skim through the doc and get mostly what it’s telling you, you can lose data when implementing oci_bind_by_name in your code. That’s because the variable that gets bound into the name is a reference. It’s right there in the description

And again in the more verbose part of the description

Well? They really mean It!

I usually iterate through arrays with for $x=0; $x<count($arrayOfData);$x++ — which is fine because $arrayOfData[$x] is a valid location in memory that contains the data I want. I had a program, though, that accepted user input. Input that frequently contains a bunch of extraneous newline characters in the middle of the data. To avoid making the users clean up their input, I just threw an array_filter on the input. But I don’t need the reorganized data, so I didn’t “waste” the cycles to re-index the filtered array. Instead, I used

$iIterator=0;
for( $itemInput in array_filter( $arrayOfData ) ) {
     oci_bind_by_name($stmt, ‘:placeholder’.$iIterator++, $itemInput);
}

Which is fine in most circumstances. But, with oci_bind_by_name … the memory address where $inputItem happened to be stashed is bound to the names :placeholder0, :placeholder1, …, :placeholdern – that memory address happened to still contain the last element of arrayOfData I happened to stash there because the server isn’t so busy that memory is being reallocated a fraction of a second later. But this loop does not bind each element of arrayOfData to its corresponding placeholder — instead of saying “select * from MyTable where ID IN (1,2,3,4,5)” … I had “select * from MyTable where ID IN (5,5,5,5,5)”.

In this case you need to use the array index

for( $x = 0; $x < count( $arrayOfData ); $x++ ) {
     $strPlaceholderName = ":inputclli".$x;
     oci_bind_by_name($stmt, $strPlaceholderName, $arrayOfData[$x]);
}

So each unique memory address is bound to a placeholder.

Fortify on Demand Remediation – JSON Injection

This vulnerability occurs when you write unvalidated input to JSON. A common scenario would be using an Ajax call to pass a string of data to a file and then decoding that string to JSON within the file.

To get around the Foritfy scanning requirements you have to use base64 encoding on the string before sending it through the Ajax call:

var update = $.ajax({
    type: "POST",
    url: "SFPNotesUpdate/../php/validate_notes.php",
    data: { tableData: btoa(JSON.stringify(HotRegisterer.getInstance('myhot').getData())) },
    dataType: 'json'
});

When reading the input to decode the JSON string to an array you have to perform these actions in order:

  • base64_decode the input string
  • sanitize the input string
  • decode the JSON string to an array
$tbl_data = json_decode(filter_var(base64_decode($_POST['tableData']), FILTER_SANITIZE_STRING, FILTER_FLAG_NO_ENCODE_QUOTES), true);

PHP Curl and Mangled Headers

I have PHP code that calls out to a SOAP endpoint, gets the response XML, and then does stuff. Well … that was the plan anyway. What actually happened was nothing. No error set, but the response string was null. Even adding curl debugging produced nothing. Fortunately, the endpoint is a sandbox one and thus available on http without encryption. I was going to do a network trace, so I needed to run the script from my computer. Aaaand STDOUT is where the curl debugging was going, not (as I assumed) STDERR. And look, there actually was an error. 400 bad request (how did that not come through to curl_error?!?) — and it became immediately obvious what my problem was — the content length is a quoted string instead of an integer.

Sigh! Copy/paste error where I built out my header. Cleared the escaped quotes from around the strlen call and, voila, my code works perfectly.

But a note to my future self — when PHP’s curl calls aren’t producing any output … try running it from the CLI. Or remember to add the instruction to have verbose output in STDERR!

curl_setopt($ch, CURLOPT_STDERR, $verbose);

 

Fortify on Demand Remediation – XSS Reflected

This vulnerability occurs when you accept user input and then use that input in output. The solution is to sanitize the input. The filter_var or filter_input functions can be used with a variety of sanitize filters.

As an example, code to accept what should be an integer value from user input:

     $iVariable = $_POST['someUserInput'];

Becomes code that removes all characters except for digits (and + or – signs) from the input:

     $iVariable = filter_input(INPUT_POST, 'someUserInput', FILTER_SANITIZE_NUMBER_INT);

Minimum wage profit sharing experiment

A pizza joint shared its profits with its employees and that meant the employees made $78 an hour. I’m curious if the pizzeria used a realistic calculation for profit. If so? This makes the “I cannot afford to increase my starting pay rate to attract employees, the problem is the gov’t is making people all lazy and stuff” argument clearly disingenuous.

Profits are what you make after paying for the business’s expenses — so the ingredients, power, water, advertising, insurance, employee benefits, real estate, business loans, taxes, and such are all taken out before you call it a profit. Good accounting includes future predictable expenses as well — the facility is going to require occasional sprucing up, maintenance expenses pop up, at some point they’ll need to replace the pizza oven or refrigeration units. Just like a personal budget should include “replacement car, every 10 years, that means I need to accrue $5 a day to fund that replacement” … these expenses should be estimated out and included in the net/profit calculations. It’s possible they used a far simpler algorithm for computing profits — net proceeds minus food cost (which is something most restaurants track very well) … which would render my calculations here meaningless. But I’m going to assume “profits” actually means profits in the accounting sense.

In a lot of businesses, the owner takes a salary too — no idea if owner, well, takes a salary in the first place but if they took their salary out before calculating the daily profit. I am going to assume the owner’s salary was not already deducted. Then $78 an hour isn’t sustainable because the owner needs to eat too, but the owner could take $50 an hour per employee and still pay everyone $28 an hour.

Not that the owner gets $50 an hour for being open, but $50 a man-hour worked by any employee. Think about that for a minute — say they’ve got three people doing prep from 1P-3P and five people working when open from 3p-10p, then thee people staying on for close from 10-11P … that’s 44 man-hours worked that the owner’s keeping at $50 a man-hour. Owner keeps $2,200 each day, plus has his business has all of its expenses covered. For each of the 300 days a year they are open (since they’re open 7 days a week, this is a low estimate too), that’s $660,000.

Say I’m overestimating the owner’s share a lot — let’s cut that in half. Maybe they did the profit sharing on an unusually profitable day. Maybe they did it on a weekend day where they’re open a few more hours. Let’s say the owner can keep $1,000 a day . That means the owner pays the staff $28 an hour, pays for all of the business expenses, *and* has absolute minimum $300,000 in profit.

Fortify on Demand Remediation – Introduction

The company for which I work signed a contract with some vendor for cloud-based static code analysis. We ran our biggest project through it and saw just shy of ten thousand vulnerabilities. Now … when an application sits out on the Internet, I get that a million people are going to try to exploit whatever they can in order to compromise your site. When the app is only available internally? I fully support firing anyone who plays hacker against their employer’s tools. When a tool is an automation that no one can access outside of the local host? Lazy, insecure code isn’t anywhere near the same problem it is for user-accessible sites. But the policy is the policy, so any code that gets deployed needs to pass the scan — which means no vulnerabilities identified.

Some vulnerabilities have obvious solutions — SQL injection is one. It’s a commonly known problem — a techy joke is that you’ll name your kid “SomeName’;DROP TABLE STUDENTS; … and most database platforms support parameterized statements to mitigate the vulnerability.

Some vulnerabilities are really a “don’t do that!” problem — as an example, we were updating the server and had a page with info(); on it. Don’t do that! I had some error_log lines that output user info that would be called when the process failed (“Failed to add ecckt $iCircuitID to work order $iWorkOrderID for user $strUserID with $curlError from the web server and $curlRepsonse from the web service”). I liked having the log in place so, when a user rang up with a problem, I had the info available to see what went wrong. The expedient thing to do here, though, was just comment those error_log lines out. I can uncomment the line and have the user try it again. Then checkout back to the commented out iteration of the file when we’re done troubleshooting.

Some, though … static code analysis tools don’t always understand that a problem is sorted when the solution doesn’t match one of their list of ‘approved’ methods. I liken this to early MS MCSE tests — there was a pseudo-GUI that asked you to share out a printer from a server. You had to click the exact right series of places in the pseudo-GUI to answer the question correctly. Shortcut keys were not implemented. Command line solutions were wrong.

So I’ve started documenting the solutions we find that pass the Fortify on Demand scan for everything identified in our scans — hopefully letting the next teams that use the static scanner avoid the trial-and-error we’ve gone through to find an acceptable solution.