Stripe's web security CTF's Level 1 and level 2 of the Stripe CTF had issues with missing input validation solutions described below.
$filename = 'secret-combination.txt';
extract($_GET);
if (isset($attempt)) {
$combination = trim(file_get_contents($filename));
if ($attempt === $combination) {
The issue here is the usage of the extract php method which extracts name value pairs from the map input parameter and creates corresponding local variables. However this code uses $_GET which contains a map of name value pairs passed in the query of the URI. The expected behavior is to get an attempt variable out, but since no input validation is done I can provide a filename variable and overwrite the value of $filename. Providing an empty string gives an empty string $combination which I can match with an empty string $attempt. So without knowing the combination I can get past the combination check.
Code review red flag in this case was the direct use of $_GET with no validation. Instead of using extract the developer could try to extract specifically the attempt variable manually without using extract.
$dest_dir = "uploads/";
$dest = $dest_dir . basename($_FILES["dispic"]["name"]);
$src = $_FILES["dispic"]["tmp_name"];
if (move_uploaded_file($src, $dest)) {
$_SESSION["dispic_url"] = $dest;
chmod($dest, 0644);
echo "Successfully uploaded your display picture.
";
}
This code accepts POST uploads of images but with no validation to ensure it is not an arbitrary file. And even though it uses chmod to ensure the file is not executable, things like PHP don't require a file to be executable in order to run them. Accordingly, one can upload a PHP script, then navigate to that script to run it. My PHP script dumped out the contents of the file we're interested in for this level:
Code review red flags include manual file management, chmod, and use of file and filename inputs without any kind of validation. If this code controlled the filename and ensured that the extension was one of a set of image extensions, this would solve this issue. Due to browser mime sniffing its additionally a good idea to serve a content-type that starts with "image/" for these uploads to ensure browsers treat these as images and not sniff for script or HTML.
This document defines several Structured Syntax Suffixes for use with media type registrations. In particular, it defines and registers the “+json”, “+ber”, “+der”, “+fastinfoset”, “+wbxml” and “+zip” Structured Syntax Suffixes, and updates the “+xml” Structured Syntax Suffix registration.
Mime-type for describing the difference between two JSON resources (in JSON using JSON paths)
Irritatingly, my G1 won't show me PDFs so I've made the Google Docs PDF viewer which will load PDFs on the web up in Google Docs. Google Docs has the useful ability to display PDFs in web browsers without any Adobe software and works (mostly) on Android.
This was very easy to put together as an Android activity. First its necessary to register the application as handling PDFs from the web. This is done via the intent-filter declaration in the manifest:
intent-filter
action android:name="android.intent.action.VIEW"/
data android:scheme="http" android:mimeType="application/pdf"/
category android:name="android.intent.category.DEFAULT"/
category android:name="android.intent.category.BROWSABLE"/
/intent-filter
The action part says my activity will view PDFs, the data part says it accepts data with the PDF mime-type and with a URL that has an HTTP scheme. The browsable category
is necessary to allow links from a browser to open this activity.
Second, the activity opens up the browser to Google Docs pointing to the PDF.
Intent intent = new Intent();
intent.setAction(getIntent().getAction());
intent.setData(Uri.parse(
"http://docs.google.com/gview?embedded=true&url=" +
percentEncodeForQuery(getIntent().getData().toString())));
startActivity(intent);
This is very simple code to invoke a new intent browsing to a newly constructed URL for the PDF in Google Docs. That was easy.
I finally replaced my old regular cell-phone which was literally being held together by a rubber band with a fancy new G1, my first Internet accessible phone.
I had to call the T-Mobile support line to get data added to my plan and the person helping me was disconcertingly friendly. She asked about my weekend plans and so I felt compelled to ask her the same. Her plans involved replacing her video card so she could get back to World of Warcraft and do I enjoy computer gaming? I couldn't tell if she was genuine or if she was signing me up for magazines.
I was with Sarah in her new car, trying out the phone's GPS functionality via Google Maps while she drove. I switched to Street View and happened to find my car. It was a weird feeling, kind of like those Google conspiracy videos.
The phone runs Google's open source OS and I really enjoy the application API. Its all in Java and URIs and mime-types are sort of basics. Rather than invoking the builtin item picker control directly you invoke an 'intent' specifying the URI of your list of items, a mime-type describing the type of items in the list, and an action 'PICK' and whatever is registered as the picker on the system pops up and lets the user pick from that list. The same goes if you want to 'EDIT' an image, or 'VIEW' an mp3.
I wanted to replace the Google search box gadget that appears on the home screen with my own search box widget that uses OpenSearch descriptors but apparently in the current API you can't make home screen gadgets without changing parts of the OS. My other desired application is something to replace this GPS photo tracker device by recording my location to a file and an additional program on my computer to apply those locations to photos.