Leonardo Garcia Fischer

LinkedIn Facebook Twitter Feeds

How to (NOT) put holes in your application: SQL injections

04Dec'11

Written by Leonardo Fischer

Hi,

I was asked at work to give some help to a colleague about SQL injections. He doesn’t know too much about the topic, so I wrote him a mail introducing the problem. This post is a little more than that mail has.

Note: this is an introduction to SQL injections, not an “all you need to know”. Use it to introduce yourself to the problem and learn how to avoid the most common mistakes. But don’t believe that it will solve all your security problems. This book covers a lot of points of SQL injections and ways to avoid it. And this other book covers several other points on securing your website.

Who invented SQL injections?

I like the “learn by example” method. So let’s start with one. Suppose you are the newest employee at Google. Your first task is to rewrite the login page for the Google products because it has low performance on the server side. (Off course, things at Google should not go the way I’ll describe here. It’s just an example.)

Remembering, this is the page you will deal with:

You open the current version, see lots of stuff and you don’t understand why so much code for a simple task such as find the user on a table. Then, you delete everything and start from scratch.

Suppose that you need to code in Java, in one of those web frameworks. You start by creating a code like this:

String username = getParameter("username");
String password = getParameter("password");
String sql = "select * from users where username = '" + username +
    "' and password = '" + password + "'";
// the code that runs the query here...

Saving the password’s has is itself a topic for another post, so let’s assume that the password is stored as plain text. Now you start to test. You fill the login form as follows:

Your code will create and execute the following SQL:

"select * from users where username = 'testuser' and password = 'testpass'"

Day 1, 1:30pm: you make several tests to ensure that the page just let pass users with the correct username and password.
Day 1, 3:00pm: your code is working and running very fast, due to its simplicity. You submit it to the repository.
Day 1, 4:30pm: another employee picks up your code from the repository, and generates a new package. And then sends it to production.
Day 1, 10:00pm: one automatic job picks the package with your code and releases to the public.
Day 2, 11:00am: several tech blogs writing news about security issues in the Google login.
Day 2, 2:00pm: you are screwed.

“Help-me!! I don’t know what I did wrong!!”

Hackers are everywhere and some of then use Google. And some of those hate Google’s new design. One of them has filled the login form as follows:

How strange is this username… Let’s see the generated SQL query.

"select * from users where
    username = 'somegoogleusername' -- ' and password = 'thepassdontmatter'"

Did you get the SQL injection?

The way that you’ve built the SQL combined with the values that the malicious user filled on the forms resulted in a query that has nothing to do with selecting one specific user from the database and checking his password. On the first point, it is searching for the username somegoogleusername. Remember that the -- in several SQL dialects means the same as // in most common programming languages: a comment until the next line break. The comment on the SQL forces an “ignore the password comparison” behavior. Resuming, the malicious user gained access to somegoogleusername account. If this is bad, imagine someone filling the username '; drop table users;--.

So, what should I do?

Please, don’t think about using complex table names or change the order of parameters in the SQL. This will just make the hacker’s job approximately 0.75% trickier.

First, what you should never do again: build a SQL with parameters by just concatenating strings. You still could use this approach if you remember to escape special characters on the parameter values. But this way is error prone, as is easy to forget to escape one parameter. Also, your code will be a lot harder to read and maintain latter. MySql with PHP lets you do this through the mysql_real_escape_string() function.

Now I’ll show you a more interesting solution. Good APIs to manage your database through code provide some ways to insert parameters in a SQL query.

The way that I like most is the “named parameters” approach. You will write the query using some placeholders for the parameters, and these parameters will be provided at the time of the execution of the query. Hibernate support this in the following way:

String sql = "select * from users where username = :pusername "+
    " and password = :ppassword ";
Map params = new Map();
params.put( "pusername", getParameter("username") );
params.put( "ppassword", getParameter("password") );
// the code that runs the query here...

One other way is “positional parameters”, which uses a question mark (?) instead of a name preceded by a colon (:). I don’t like this one because if you rewrite the query and change the position of the parameters, you need to change the order of the values in the list you pass to the API (yes, I’m lazy). But you still can use this if you like. The Java JDBC API provides the PreparedStatement for this.

And there are other ways to do this. The Grails framework supports the “criteria” way to write SQL queries: you write the SQL code in Groovy, and the framework takes care to build the SQL string for you.

I believe that these two are the most common among several languages/programming APIs. But there are others for specific frameworks.

I hope this helps you understand SQL injections. If you have any doubt about the topic, please let me know. If you already know about the topic, leave your thoughts about it on the comments.

Tags:

No comments yet

NinePatches, backgrounds, paddings, relayouts and some headache

10Nov'11

Written by Leonardo Fischer

Hi,

A few days ago I got stuck into a so called “bug”. A developed a small NinePatch to use in an Android app. I wanted it to highlight a ViewGroup object, and then remove the background later. But the first time I set the NinePatch, the view appears to move a little bit. Weird!

Let’s start from the beginning: what is a NinePatch?

It is a special image file. In the Android SDK, it is a file with the extension .9.png that you can open in any image editor. What makes it special is a border around the image that has a special meaning for the Android system. If you ask to draw this image with a different size than its width*height dimensions, the image will stretch only in some pre-defined areas and the others will keep their original size. Why you would use this?? A practical way to explain this is to show you a NinePatch in use:

There is a NinePatch on the left (with a lot of zoom, and a yellow line to the actual NinePatch dimensions). On the right, two buttons with different dimensions. You got it? The NinePatch is very stretched on the big button, but still look very good! There is a lot of material explaining how to get this effect on the web. I recommend you the official Android SDK for this (which also is the source of the image with the buttons, modified by me). The Android SDK also have a very simple tool that let’s you generate these NinePatches.

The Symptom

So far, so good, the NinePatch works pretty well. Until you put it behind a view as its background. What happens? Let’s see.

After I set the NinePatch as the background of the FrameLayout root_layout, the text is moved some pixels down (I drew a blue line so you can see that it moved exactly 4 pixels). Not too much, but it should move 0 pixels, no more, no less!

The Research for the Cure of the Headache

Well, actually the “bug” is not a “bug”, but a feature! After researching the Android source a little bit, I understood that the optional padding that you should set in the NinePatch also gets into account when you set the ViewGroup’s background. Let’s look at the source of the method View.setBackgroundDrawable(Drawable d).

public void setBackgroundDrawable(Drawable d) {
    //some other code
    if (d != null) {
        Rect padding = sThreadLocal.get();
        //more intermediate code
        if (d.getPadding(padding)) {
            setPadding(padding.left, padding.top, 
                padding.right, padding.bottom);
        }
        //more code
    }
    //and the finishing code
}

The Medicine

As you can see, the view literally gets the padding that you set into the NinePatch and sets onto the view, changing its dimension. That is why you set the background and the view changes its position. If you do not set the optional padding, the padding of the NinePatch will be computed from the stretchable area, and will mess with your beautiful layout.

Optionally, you can get the padding before set the background, set your custom background, and then set the old padding. Example:

//backup the old padding
Rect padding = new Rect();
padding.left = rootLayout.getLeft();
padding.top = rootLayout.getTop();
padding.right = rootLayout.getRight();
padding.bottom = rootLayout.getPaddingBottom();
//set the new background
rootLayout.setBackgroundResource(R.drawable.nine_patch);
//restore the old padding
rootLayout.setPadding(padding.left, padding.top, 
    padding.right, padding.bottom);

This one is not as good as just set the padding on the NinePatch, as you need to run some extra code every time you set a background onto a view. But this hack may let you do something that I did not though of yet ツ

The Side-Effects

Finally, I want to show you a side effect of using a NinePatch. Let’s go back to the Android source code:

public void setBackgroundDrawable(Drawable d) {
    boolean requestLayout = false;
    //some initial code
    if (d != null) {
        // some other code, including the one presented above
        if (mBGDrawable == null || 
                mBGDrawable.getMinimumHeight() != d.getMinimumHeight() ||
                mBGDrawable.getMinimumWidth() != d.getMinimumWidth()) {
            requestLayout = true;
        }
        // more code
    }
    // pre-requestLayout code
    if (requestLayout) {
        requestLayout();
    }
    //finishing code
}

As you can see, if the previous background has different minimum width or height from the new one, the method will force a requestLayout() call. This is ok if you set the background during the application initialization. But if you start to swap your view’s background, then you need to take care of these properties too. If not, your application may suffer from “hiccups” from the re-layout of your views.

Finishing, this is the source code that I developed for this post. It contains the “Hello World” example you saw above. If you click on the text, the background is added, so you can see for yourself this Android feature.

Tags:

No comments yet

The DCEL data structure: a C++ implementation

05Nov'11

Written by Leonardo Fischer

Hi, When working with computer graphics, it’s very common to deal with discrete surfaces (for example, triangle meshes). The simplest approach is to store a triangle mesh as a list of vertices and the indices that define the triangles, and it is very efficient if you just need to draw the scene. But it doesn’t work very well if you need to answer advanced queries, such as what are the edges that start on a given vertex or what are the neighbor faces of one given face During my master thesis I needed to answer such queries. And I found that the DCEL Data Structure would be perfect for my case. But I didn’t like the implementations that I found. For example, this one couples too much the DCEL implementation with the data that I need to store within the DCEL. And this one is a powerfully monster that should do everything I need, but only after tame de monster. I decided to write my own DCEL. I tried to keep it simple to understand, but complete enough to do all the things that I need. Basically, the vertices, edges and faces in my DCEL are containers. I also implemented a mesh template that receives the types that you want to put inside these objects. Finally, the mesh has lots of helper methods that very simple to use to manipulate the DCEL in the most common cases. I tried to keep its use in the same way that you would use a std::list.

But what is this DCEL I don’t stop talking about?

The Doubly-Connected Edge List is a data structure to store the topological structure (i.e. the relation between faces, edges and vertices) of a surface. It doesn’t solve every problem on earth, but is heavily used in algorithms that deal with surface operations. I will not go deep into how it works, but I will try to scratch its surface. It works like a double-linked list.
A DCEL is a set of faces, half-edges and vertices. Yes, an edge divided by two. A pair of half-edges forms an edge, and they are called twins. So, each half-edge has a pointer to its twin half-edge, in order to reconstruct the whole edge. But why divide an edge by two? Each half edge is associated to one face on one side of the edge, and one vertex on one end of the edge. In other words, a half-edge has a face pointer and an origin pointer. And where is the “doubly-connected” thing? Each half-edge has a next pointer and a previous pointer. The contour of a face is defined by a sequence of half-edges linked by their next and previous pointers. Finally, a face has the boundary pointer which points to one half-edge on its contour. And the vertex has an incident pointer that points to one half-edge that starts on that vertex. But why this data structure is so interesting? If you inspect it carefully, you will see that everything is connected to everything in a very organized way. From one face, you can walk through his contour by following the next (or previous) pointers of its boundary. From one half-edge, you can access one vertex through the origin pointer and the other vertex following its twin->origin pointers. In the same way, from a half-edge you can access the face on which it is part of the contour (by its face pointer), and the other face by its twin half-edge (twin->face pointer). As you can see, it is easy to answer the questions from the beginning of the post. What are the edges that start on a given vertex? Pick the vertex. The first half-edge is in its incident pointer. Call it current. For the next half-edge, pick the previous->twin half-edge of the current half-edge (and call this new one the new current). Keep getting these previous->twin pointers until you reach the first half-edge, and you did it!!! What are the neighbor faces of one given face? This one I left as exercise ツ If you want to dive in the DCEL data structure, I recommend you this page. Or this book.

Building a DCEL using templates

From now on, I’ll assume that you are an expert on DCEL, and I’ll focus on the DCEL implementation. Let’s start by creating a template for the three main objects: FaceT, HalfEdgeT and VertexT (don’t worry about the “T” in the names. It will “disappear” latter). These templates will hold the objects that the face, vertex and half-edge should hold as an internal data pointer. I could put a void* on these objects, but this way the object and the data associated will be in the same region of the memory (thus, improving cache hit). Also, it still allows you to use a pointer to any type want.
template
class FaceT {
public:
    inline FaceDataT& getData() {
        return data;
    };
private:
    FaceDataT data;
};

template
class HalfEdgeT {
public:
    inline HalfEdgeDataT& getData() {
        return data;
    };
private:
    HalfEdgeDataT data;
};

template
class VertexT {
public:
    inline VertexDataT& getData() {
        return data;
    };
private:
    VertexDataT data;
};
Now, let’s fill the pointers between the objects. Before we add the pointers itself, I need to create forward declarations for the templates.
template
class FaceT;

template
class HalfEdgeT;

template
class VertexT;

template
class FaceT {
    typedef HalfEdgeT HalfEdge;
    typedef FaceT Face;
public:
    //getters and setters, with an inline tip to the compiler =)
private:
    HalfEdge* boundary;
    FaceDataT data;
};

template
class HalfEdgeT {
    typedef VertexT Vertex;
    typedef HalfEdgeT HalfEdge;
    typedef FaceT Face;
public:
    inline void setTwin(HalfEdge* newTwin) {
        this->twin = newTwin;
        newTwin->twin = this;
    };
    inline void setNext(HalfEdge* newNext) {
        this->next = newNext;
        newNext->prev = this;
    };
    inline void setPrev(HalfEdge* newPrev) {
        this->prev = newPrev;
        newPrev->next = this;
    };
    // all the other getters and setters as usual
private:
    HalfEdge* twin;
    HalfEdge* next;
    HalfEdge* prev;
    Vertex* origin;
    Face* face;
    HalfEdgeDataT data;
};

template
class VertexT {
    typedef VertexT Vertex;
    typedef HalfEdgeT HalfEdge;
public:
    //all the getters and setters as usual
protected:
private:
    HalfEdge* incidentEdge;
    VertexDataT data;
};
Finally, let’s create the Mesh holder to keep all these objects. It will receive as template parameter all the three data types that the other objects will hold. Also, is here that the “T” from the VertexT, …, will disappear.
template
class Mesh {
    typedef Mesh MeshT;
public:
    typedef VertexT Vertex;
    typedef HalfEdgeT HalfEdge;
    typedef FaceT Face;

    typedef VertexDataT VertexData;
    typedef HalfEdgeDataT HalfEdgeData;
    typedef FaceDataT FaceData;

    // Several helper methods to deal with these objects.
    // Also, the getters and setters.

private:
    std::vector vertices;
    std::vector faces;
    std::vector edges;
};

Voilá!!! But this is everything? No.

The basis of my DCEL implementation is here. But over it, I’ve implemented several other helper methods to deal with the DCEL. It was designed to deal with faces of any shape, such as triangles, squares or megagons. But triangles are so common and used in computer graphics that I developed only the method that creates triangular faces on it. So, instead of creating the vertices, faces and edges and link everything together, you can just create the vertices and call an createTriangularFace() method on the Mesh class that the needed faces and half-edges are created and linked for you.

I also developed some helper classes. One is an EdgeIterator. If it receives a Face pointer in the constructor, it will iterate over the half-edges of the contour of that face. And if it receives a Vertex pointer, it will iterate over the half-edges that starts on that vertex. Also I developed two loaders for it, which can load common .OBJ files and some .PLY files (through this library). Finally, I developed methods to load and save DCEL structures into files, which is able to deal with the DCEL structure and the data stored in it.

You can download the entire source files here, or download/branch it on my GitHub account. The projectcontains all the headers and .cpp files for this DCEL. It also contains the main.cpp, which has some examples of how to use it. The code works on the Visual Studio 2008 and 2010. And if you have any doubt or suggestion, please leave a comment bellow ツ

Tags:

2 comments

Android SDK: Using the Scroller object to create a page flip interaction

23Oct'11

Written by Leonardo Fischer

This weekend I decided to play with the Android SDK. I decided to implement an app that uses the basic sweep gesture: you can touch the buttons, but you can drag to change the current page smoothly, or use a gesture to flip between views. The one from the Home screen of most Androids phones and iPhones. There are several solutions on the net, but I thought that it will be great if I developed one on my own. And it was ツ

So, this is my solution, the PageFlipper class. I extended the ViewGroup, so each child you add to my class will be a page on the final view. I use the onInterceptTouchEvent method to check if the user wants to drag/flip the screen or just want to click on a button on it. If I understand the user’s intent to change the page, the method returns true, and the motion of the screen is divided between the onTouchEvent and the computeScroll methods.

My solution uses a very simple State Machine. Take a look at it. I will explain the code based on it.

1) Firstly, the user touches the screen. In the onInterceptTouchEvent, I capture the initial coordinates of the touch, and changes to the state ST_WAITING. The VelocityTracker is initialized here to compute the velocity that the user moves his finger on the screen. Note that I return false from here because I want to watch the MotionEvent, but I still want to let the target child receive the event.

if (action == MotionEvent.ACTION_DOWN && getState() == ST_IDLE) {
    if (mVTracker != null) {
        mVTracker.recycle();
    }
    mVTracker = VelocityTracker.obtain();
    mVTracker.addMovement(event);
    setState(ST_WATCHING);
    mLastX = mFirstX = (int) event.getX();
    mFirstY = (int) event.getY();
    return false;
}

2) The user leaves his finger from the screen. Just go back to the ST_IDLE state, and releases the VelocityTracker object.

if (action == MotionEvent.ACTION_UP || 
        action == MotionEvent.ACTION_CANCEL) {
    setState(ST_IDLE);
    mVTracker.recycle();
    mVTracker = null;
}
return false;

3) Now the things are getting interesting. The user’s finger moved slowly across the screen. What we do here is check if he moved long enough on the horizontal axis to assume that the screen should be moved. If it is true, changes to the ST_DRAGGING state. By returning true here, the current and the next MotionEvents will be delivered direct to the onTouchEvent of my class. The ST_IGNORING is just to avoid interaction with the PageFlipper while the user is interacting with, let’s say, a list in one of the pages.

if (action == MotionEvent.ACTION_MOVE && getState() == ST_WATCHING) {
    int deltaX = Math.abs(mFirstX - (int) event.getX());
    int deltaY = Math.abs(mFirstY - (int) event.getY());
    if (deltaX > mTouchSlop && deltaY < mTouchSlop) {
        setState(ST_DRAGGING);
        return true;
    }
    if (deltaX < mTouchSlop && deltaY > mTouchSlop) {
        setState(ST_IGNORING);
        return false;
    }
}

4) While the user is moving his finger on the screen, I scroll the view. Doing this way the user can actually drag the views on the screen.

if (getState() == ST_DRAGGING && action == MotionEvent.ACTION_MOVE) {
    int deltaX = mLastX - (int) event.getX();
    scrollBy(deltaX, 0);
    mLastX = (int) event.getX();
}

5 and 6) When the user stops touching the screen, the state changes to ST_ANIMATING. Here are several things to do. First, I use the VelocityTracker to compute the speed that the user moved his finger. If it is greater than a minimum speed, the animation will scroll the view to the next child on the left or right. If the user moved his finger slowly, but for more than 50% of the screen, it is moved to the left or right too. If not, then move the view to the correct position back again.

if (getState() == ST_DRAGGING && (action == MotionEvent.ACTION_UP
        || action == MotionEvent.ACTION_CANCEL)) {
    setState(ST_ANIMATING);
    mVTracker.computeCurrentVelocity(1000);
    float velocity = mVTracker.getXVelocity();
    final int width = getWidth();
    final int delta = mLastX - mFirstX;
    final boolean fling = Math.abs(velocity) > mFlingSlop;
    final boolean moveToNextScreen = Math.abs(delta) > (width / 2);
    if (fling || moveToNextScreen) {
        int motion = (delta > 0 ? -1 : 1) * (width - Math.abs(delta));
        mScroller.startScroll(getScrollX(), getScrollY(), motion, 0);
    } else {
        mScroller.startScroll(getScrollX(), getScrollY(), delta,  0);
    }
    invalidate();
    mLastX = mFirstX = mFirstY = -1;
    mVTracker.recycle();
    mVTracker = null;
}

Note that I call the invalidate() method on the end. This will force the view to redraw itself. But before that, the SDK will call the computeScroll() method, which is the key to animate the scroll of our view. Note that the methods scrollTo() and scrollBy() just move the view at once to the specified position. So, the Scroller object will help us to move just a little bit at a time, to give the feeling of an animation.

7 and 8) Finishing the main code, our computeScroll() will be called after the call to invalidate() that we did before. The computeScrollOffset() method will return true until the scroll has been completed. So we move a little bit again the view, and call invalidate() again. When the scroller is finished, go back to the state ST_IDLE.

public void computeScroll() {
    if (mScroller.computeScrollOffset()) {
        scrollTo(mScroller.getCurrX(), mScroller.getCurrY());
        invalidate();
    } else {
        if (getState() == ST_ANIMATING && mScroller.isFinished())
            setState(ST_IDLE);
        super.computeScroll();
    }
}

There are some points that I didn’t solved in this code. One is that the view gets lost if you try to sweep to the left of the first view or the right of the last view. Also, if you add a child view that doesn’t receive touchEvents (such as a TextView), the MotionEvents are not working as I would expect. You need to call setClickable(true) in these cases.

Please, download the full source code of the PageFlipper class and an running example. I hope that you can use it for your projects. And, if you use it or find a bug, please leave a comment bellow ツ

Tags:

3 comments

Going to the supermarket

21Oct'11

Written by Leonardo Fischer

A few months ago, I developed with some friends at UFRGS a solution for the 3DUI Grand Prix. In a few words, it was a contest to see who develop the best solution to interacting with a virtual market.

For now, I’ll just share the code, the paper and some other stuff about this work. So, please fell free to download the article and the source code. Below, you can see some images and a video of it running.

Highslide JS
Highslide JS Highslide JS Highslide JS Highslide JS Highslide JS Highslide JS Highslide JS

Tags:

No comments yet

css.php