Changing Directions

This blog has served me well over the last few years.  However, for reasons of my own sanity, I’ve decided to consolidate my blogging efforts on blogger. Furthermore, this name and title is no longer the best representation of who I am and where I am at.  This started as a developer blog, writing on developer things.  As I’ve formed a more solid identity as a security engineer & penetration tester– this place doesn’t feel like my own skin.

That doesn’t mean I will not be blogging.  To the contrary, I am going to be contributing more in other places.  My new personal blog,  “Fuhyô no Michi” (不評の道), can be found here:

I also am now VERY excited to be contributing technical posts to Attack Research / Carnal0wnage.  These guys have impressed me with their technical skill and insight for a while– I hope to be able to keep up with that tradition.  That blog can be found here:

Finally, I am soon to be blogging with another group (not yet announced).  I will update this post to include those details once they are available.  This blog will remain available for historic reasons.

Thank you for bearing with me.



Crossfit: Forever Strong

Let me first start this post off with an assurance I haven’t forgotten the series.  I’ve been working on a few articles, however I keep finding vulnerabilities in things I wanted to show, so I have to wait till i can find something I can.

However, since those articles aren’t ready for the public yet, I wanted to write about something else important to me– my family’s health.  A few months ago I reached out on the tweeters for ideas on a “bootcamp” style work out program.  One of my coworkers (dasfiregod) answered that crossfit might suit my needs.  It did, and then some.

I did a quick search online for gyms near us and found a handful.  I’ve always been interested in a military style/cross functional program– and this struck a nerve right away.  I visited one of the gyms, and immediately fell in love with the place.  I forced convinced my wife to join as well– and such our journey began.

Fast forward six months later.  I personally have lost 20 pounds since starting.  My wife has had similar results and hasn’t been at her current weight since high school.   My body fat percent was somewhere around 28% or so when I first started– it is 19.2% now.  The results speak for themselves.

But it’s more than just the results– the gym I go to (crossfit forever strong) has become like a 3rd family.  I wish I could explain this better, but the people there genuinely get excited and care about you and your growth.  Many of the people even go to my church– one of which was in a preparation for marriage course 5 years ago.  I have never been excited to go to a gym… until now.

So– there is hope.  I am not unique, but I thought of some tips to share:

  • Water is important.  I drink about 1 gallon of water a day now.
  • Your mind wants to play tricks on you.  You ARE capable– let your body do the talking.
  • If that’s not helpful, use music.  It’s the lubricant that lets me ignore the evil noises in my head.
  • Paleo diet is a great portion of our success.  It took a bit to transition, and we aren’t zealots.  I put cream in my coffee.
  • Hard work and amazing trainers (Jason & Sally) are the other portion of our success.

Causalities of Errata

To preface the rest of this article, I am aware that I am upset right now.  I try not to write when I am like this, however the BSides drama has already caused a potential sponsor to back out.  This might leave me and some others with large bills to pay.  I know that God provides, but I am disappointed with the decisions of others.

Also to be clear, I don’t want to be involved with any of the shenanigans in this.  I don’t want the local BSides conference we are organizing to be involved in this.  But we already are– so I am weighing in publicly.  First and foremost– I don’t know who is right or wrong in all of this.  The issues presented, to me, come across as personal problems with a few people.  That doesn’t mean there isn’t some truth to the errata article, but it also doesn’t make MikeD a charlatan because he isn’t “open minded” and won’t reply to someone’s email.  There are some legitimate concerns about non-profit status and transparency, but there are mountains and there are mole hills– this is a mole hill.

The way the evidence has been presented is irresponsible.  There are better ways to have brought these concerns up that would have been less damaging.  If mommy and daddy need to fight, they should do it in private and not in front of the kiddos.  The public fashion this was done in has already negatively impacted these conferences– despite the reality that this could all just be a misunderstanding.

All that said, I want to offer some assurances to our sponsors and everyone as a whole.  First as foremost, we intend to make no money off of the local BSides Phoenix event.  Money is being collected through my personal company mostly as a legal shield.  I am willing to disclose, upon request, all of the funding details and receipts of expenses.  These are already being communicated internally to the group.

In the case that any extra money is left over (which at this point is seemingly less likely)– the remaining balance will be donated to a charity such as EFF or Hackers for Charity.  That will also be made public upon request.

I am not asking you to trust BSides, I am asking you to trust me.  This event is to be for the local community’s benefit.  Please don’t let this drama detract you from supporting us in our project to do so.

Grammar: The Stuff of Exploits

Communicating clearly can be difficult.  Consider the following sentence:

The police officer and bandit pulled their triggers.  Shots were fired, and he went down.  He breathed his last breath.*

This sentence is a legitimate use of language– however it is awkward because of an unclear antecedent.  Who shot who in this sentence?  Did the police officer shoot the bandit? Did the bandit shoot the police officer?  The reader is left to make up his/her mind on how to handle this.

Written or spoken, clarity of language is accomplished by removing such ambiguities.

But I am not in the business of copy editing.  My job is to lie to computers and people, as a means to circumvent filters and exploit weakness.  Because people write software, it should be unsurprising that similar types of ambiguities can be used against applications.

Consider the following URL scheme**:;

If you use this URL in internet explorer you are taken to, if you use this URL in most other browsers you are taken to  This is because of the same type of issue we faced with our poorly written sentence.  It is perfectly valid syntax, however it is ambiguous to intent and causes the reader (aka: browser) to make a decision as to what was intended.

Languages support these types of clauses because, when used properly, they can be useful.  But when ambiguous situations arise, it is nearly impossible to make “the right” decision.  You can, at best, make a decision– but who can say if it was a good one.

If you think you have it right– look back again at the first sentence.  Because of the way this information is presented, our mind is drawn into the assumption that the police officer and bandit shot each other.  But why?  In context, it is entirely possible that they both shot at someone else entirely.  When you add scope into the mix, context can change in radical and unpredictable ways.

This reality is horrible for anyone who is trying to identify “malicious” data.  You don’t often know what is malicious until it is too late, and can’t exactly not permit language clauses that are useful.  These leaves lots of room to shuck and jive– often to your detriment.

Welcome to grammar.


(I really am not a copy editor, nor do I have one.  If there are mistakes with this post– please be kind.)

* Example based on the book, “It was the best of sentences, it was the worst of sentences” by June Casagrande
** Example borrowed with permission from the amazing book, “Tangled Web” by Michal Zalewski

Reverse Engineering Web Apps: Architectural Composition

Don’t worry, give it 10 years and you will be an overnight success.  – K. Slatoff

Since our process of reverse engineering relies heavily on pattern matching, being capable of identifying and decomposing architecture is a critical skill.  Unfortunately, there aren’t very many short cuts here.  I personally feel as though this skill is one of my greatest strengths, but it took 9 years or so of developing software to get here.

In spite of that you still need to be familiar with common patterns to do the real work of web application reversing & penetration tests.

Compiled binaries have a bit of a leg up on us here.  When you download an application the file format is generally fairly easy to determine.  This gives you some very key insights into how an application works, where data is stored, and its structure.  This is not true of the web.

Luckily for us, developers have a penchant for reusability.  This means that their applications are built on top of frameworks, leverage shared components, and are most often structured in known/public ways.  Patterns and algorithms are the cornerstone of proper engineering.  Which is also great because even if an ‘engineer’ isn’t proper– they still rely on things which are.  If you’re using MVC.Net to build your application, regardless of your skill level, you have to go out of your way to not use MVC.  This is true for all other frameworks as well.

Web Patterns

One of the best resources I’ve found for this is Martin Fowler’s Patterns of Enterprise Application Architecture book.  Subsequently, he has published a briefing on many patterns here:

Since we are discussing web apps, the web application presentation patterns are of most interest.  Read up on all of them, but in particular I find that 3 patterns are most popular.

Page Controller 

In this pattern, the page itself is the controller– which is just a fancy way of saying it’s responsible for binding the model (core application data) to the view (user interface presentation).  This is pretty easy to spot as the page name is the action it wishes to perform (such as:,, etc…)

In this pattern, I treat each page as its own API since the ProductEdit page is likely to expect a whole different set of parameters than ProductDelete.  For all intent and purpose, each page is a silo– loosely communicating with each other through querystring, cookie, or POST parameters.

Front Controller

A front controller is a somewhat similar pattern.  The page itself is a type of controller, except that it mostly operates as a router of commands.  Drupal and WordPress work this way, despite their ability to appear as MVC.

In this pattern, you see pages like:


This is either applied broadly (such as an index.php page) or more specifically to a functional area. (such as product.php?action=edit).

In either case, it’s also fairly straight forward to decompose.

The scope of the API to communicate with these types of applications is based on the scope of the controller.  In a global scope, index controller has to support all of the parameters that could come through it.  Though these commands may be ignored, the general size of the API is often fairly large.  In the more focused scope, the API is usually more focused.  It is not uncommon to be able to call admin commands from a less-than-admin controller if the ACL on the commands is not setup correctly.  It is also easy to guess that there might be an action=edit if you see lots of action=view type commands.

Model View Controller (MVC)

In this pattern the URL structure is more than a resource locator– its a syntax for communication (also referred to as RESTful).  In this pattern you have a clear abstraction of the view, the model and the controller.  This usually looks something like:


There are of course variants of this syntax, for instance a default action and default controller could be used and allow for a call like:

/Products/id == returns the view action for the id.
/id == returns the view action of products by id

This pattern also creates some interesting dynamics as far as composition is concerned.  Consider, that while the latter call will work, you might ALSO be able to call this page by doing /Views/Products/Edit.aspx and POST and ID to the page.  This can create interesting side effects if permissions are not set correctly (especially for partial views and JSON results).

This pattern has become super popular among many frameworks.  Ruby, Python, MVC.Net, Spring, Struts, etc… all use this pattern primarily for their web applications.

Notable “Stuff”

The aforementioned patterns are considered “enterprise patterns” specifically related to architecture.  Component patterns (or design patterns) are also important to understand since they are how individual components are built.  Since this post is already somewhat long, we will talk more about component based composition discovery next time.

The rest of the ‘stuff’ below represent patterns which fall into categories less easily spotted on a webpage– but are useful in figuring out how something works. Unless a developer mistake short cuts this process (such as an exception with a full stack trace), you can only reliably get an understanding about these components through interaction.

Data Access Patterns

There are three means of data access which are important to have some exposure to.  This is more useful to note if you have SQL injection, but can be helpful in identifying points in the application which MIGHT be vulnerable.

These three access patterns are: string concatenation (aka: evil), parameterized queries (most common), and stored procedures.

There are very subtle and unique ways to figure out how the data access pattern is composed, but the SQL injection Attack and Defense book does better job of outlining them than I will attempt.


You are also unlikely to be able to reverse an algorithm used on the web, with perhaps the exception of various cryptographic ciphers or hashes.  But you ought to be familiar with various important algorithms, as lists and data retrieval and binding are things which come in handy in more advanced attacks.  You ought to know the differences between Linked Lists and Sets, for instance.  Most web applications just use generic or typed lists, however I’ve run into situations where understanding how the data was being cached (as a Set) made it possible to short cut the caching mechanism (which was important so I could generate the pages uniquely each time).

There are super formal algorithm books, but also good introduction ones.

AJAX Patterns

AJAX patterns are also very useful to be able to identify in the testing of a site.  OFTEN these represent great chances to bypass WAF or application level input filtering mechanisms.  There are basically only three approaches to this.  The first puts the processing of the display entirely in the hands of the client (and just sends raw JSON back to the AJAX call).  The second is that the entire component is returned, processed by the server.  This approach was favored for a while in ASP.NET Ajax’s mechanisms.  The final is a hybrid where parts are processed server side, parts are processed local client.

How much you will be able to manipulate these features later will depend largely on how they are composed.


Patterns are ubiquitous and unavoidable.  They range from the super formal to something more commonly known as spaghetti.  This mess, (their mess) is one of the first things you are going to be unpacking as you work through a site.  Applications might be a mix of one or more of these patterns, as each component they might implement could leverage a different pattern for it’s development.

Understanding architectural composition is my ground zero of a test– a scoping step if you will.  It is a lot of information to grok, but once you can it only takes a few minutes to figure out.  The best way to get experience with this is to build sites with these various approaches.

But I reiterate, this skill dictates where the entire rest of the test goes.  I believe that composition is destiny– at the very least it’s a predisposition.  Each pattern has strengths and weaknesses, which you can only take advantage of if you have the chops to first recognize them.  MVC for instance suffers from model binding (aka mass assignment) attacks, whereas front controllers might have command injection / authorization issues.  I stack the deck as much as I can here and try to know more about architecture than the developers themselves.

If I were going to train a person on web application testing in general, enterprise and design patterns would be where I spent nearly all my time for a while.  More on design patterns next time.