An open and interconnected application infrastructure is a reality for more and more companies each day. Keeping these types of open infrastructures secure for users is a challenge. I’m convinced the old ‘’throw a firewall around it to secure the perimeter” is almost as obsolete as having a castle moat to secure a castle. How can you keep these open applications secure though?

As a backend developer or DevOps engineer you have to be constantly aware of potential security issues on the (backend) application level. This is even more the case when your backend application – like our Online Video Platform – needs to be accessible from locations all around the world.
Regular security tests (preferably done by a specialised firm) will reveal possible exploits hopefully before they’re found and used by malevolent individuals.
In this blog post I’ll talk you through a few potentially unsafe situations that were found and how we resolved them in our web based application backend.

Session fixation

Assumption is the mother of all…

Every once in a while this old and wise saying pops up in my head as another fundamental piece of technology I’d never questioned before appears to be a lot less safe than expected.

We found out something new. Something scary: the PHP session ID – the key to a user’s session with the Online Video Platform  backend – can be determined up front.
“Well, how is that really a problem?” I hear you think… Let me explain: A hacker could fabricate a cookie with a self-named session. For this to work he would either have to have access to the victim’s computer at some point before the victim would use the Online Video Platform  or make use of a client side (Javascript) exploit to inject a cookie via a URL he lured the victim to visit.
When the victim would then log in to the Online Video Platform  the logged in session would actually be bound to the session name/ID the hacker had made up. This enables the hacker to hijack the established session simply by fabricating a session cookie with that same name on his own computer. We assumed the session ID could not be that easily dictated by a client. We were wrong.
To eliminate the possibility of such an attack we’ve taken several measures:

  • ​Session renewal after successful login:
  • When a user logs in his session is renewed (with a server generated session ID). This way the hacker hasn’t got a session ID in his possession that is actually usable.
  • Session destruction after successful logout
  • When a user logs out his session is removed. This prevents a possibly “leaked” session ID from being used again.
  • Session cookie marked “http only”
    This prevents the session cookie – the key to the user’s established session – from being read or written by client side (Javascript) code. Fortunately all modern browsers (at least the latest versions of Opera, Internet Explorer, Safari, Chrome and Firefox) support this type of session cookie protection.
  • Force SSL for all authenticated sessions
    When preventing the user from establishing a logged in session over unencrypted HTTP the user is protected from any hackers listening in on his HTTP traffic to the backend server.

For a detailed technical explanation of the term “session fixation” I recommend to read  https://www.owasp.org/index.php/Session_fixation

CSRF (Cross Site Request Forgery): Click to win.. And let me use your own hands to destroy your work.

CSRF is all about tricking a victim into accessing secure URLS on an already established session. I’ll give an example: A user has logged into the Online Video Platform using his favorite (and default) browser and then gets distracted by a new mail message stating: You’re going to be very rich very soon. The user opens this mail message and sees a link inviting him to “click and win”.  What the user doesn’t see is that this link actually points to an Online Video Platform  URL that removes a video from the system.
How is this possible? The link the user clicks on opens in the user’s browser where he already has an authenticated session.
The session cookie will be sent automatically with the link the user visits Therefore the system will simply execute the request to remove the video. Of course this describes quite an unlikely situation. Nobody in his right mind would click on a “click to win” link in an email message. However CSRF attacks can also be covered up quite nicely, using for instance an image which actually points to a destructive API URL:

<img src=”http://myapi.com/removeAllContent?areyousure=yes”/>

To prevent a CSRF attack we’ve enabled the use of an extra session token that needs to be transmitted either using the URLs to the Online Video Platform backend or via the HTTP request headers to said backend. A hacker can never know that unique session token up front and is not able to include it in a malicious email message or any other “trick site”.

During the first handshake from client to server the client requests a session token from the server.

/api/bbauth?sesstoken=set

On succesful login the server responds with the user information and a unique session token. When the backend receives a request with a valid session cookie but without this session token the session will not be used. That means the user won’t be logged in for that specific request and no damage can be done.

I hope to have provided you with a some insight on typical backend security issues and how we’ve eliminated them. These are just a few examples of how we protect our customers and their content from hackers and thieves.
If you’d like to know more about backend security measures or any other Online Video Platform  related security topics don’t hesitate to contact us.