Tag Archives: web development

Further update on SAP Gateway CSRF token farce

So an update on recent rant about CSRF protection that isn’t needed on SAP Gateway.

The folks in the very attentive HCI team have just added functionality into their solution, so if you configure an OData call to an onPrem system via SAP HANA Cloud Connector, it will automatically do the GET with a fetch for the CSRF token for you whenever you configure a data update operation.

That’s kinda cool, but all it does is sweep the offending rubbish under the rug.

https://www.flickr.com/photos/bruce_krasting/7695348682 - Sweep under the rug, credit Bruce Krasting

https://www.flickr.com/photos/bruce_krasting/7695348682 – Sweep under the rug, credit Bruce Krasting

So now we have logic built into an integration platform that is needlessly slowing our integration flow because of a superfluous system requirement. An extra round trip for no reason.

In this case it is truly superfluous, because the original PUT that I was using had the user credentials as part of the header. That alone should make the CSRF token not required.

What this does show, is how SAP Cloud solutions like SAP HCI are able to update and fix stuff far faster than their onPrem partners. Even if it is a work-around to a problem that shouldn’t exist.

Herding cats, or managing GitHub issues – Waffle and HuBoard considered

Today I needed to decide on a tool to use to manage GitHub issues. I’ve got so many of these now-a-days that it has become quite hard to decide which one to work on and also to communicate to others which ones I am working on.

So I turned to some of the simple Kanban board visualisations of GitHub issue tools that I’ve seen. There may well have been others (I’m pretty sure that it’s possible to get Trello to work with GitHub) but I wanted something that was simple.

I ended up comparing waffle.io and huboard.com .

HuBoard

I found that HuBoard had in many areas some cool functionality that could well be something I wanted. In particular it has the ability to mark a task/issue as “ready for next stage” and “blocked”. Blocked issues are particularly important to me – so having this clearly visible is important. Additionally HuBoard claims to have existing integration into Slack – that would be pretty cool, but given I already have GitHub integration into Slack, I’m not sure it’s needed. Would have been nice if the web-site had shown what that integration actually was, as that is something that could really decide me one way or other.

HuBoard has a nicely minimalistic view – more inline with newer design patterns like Android material design, SAP Fiori. Labels on issues are small colour coded lines that appear when you hover over them.

huboard design

It’s quite neat and tidy. It also has a cool “fade away” filter option that just fades out un-selected items rather than removing them (two clicks removes them). However, clicking the same button multiple times to get different affects, I’m not sure that’s really a great idea. I’ve definitely been slapped over the wrist for bad (and not very accessible) UX when I’ve done similar things in the past. But technically and from a usefulness stake (if you understand what you’re doing) that’s a pretty cool feature.

However, I there were some concerns – when I loaded the HuBoard site on my phone it was good to see that it adapted responsively to the space available and listed the items rather than displaying a grid (well, I’m still debating if that was good, but at least it was responsive.) However, when I then clicked on a issue:

mobile huboard issue small

Yuck! that’s not usable.

Edit: NB see note following stuff documented in following section about privacy has been changed.

I then looked at the site to understand what the privacy policy was:

privacy policy from HuBoard missing

The only info on the site was “This Application collects some Personal Data from its Users”.

I’m pretty sure this is because of HuBoard not paying someone for their generated policy:

huboard policy issue

 

However, I tweeted at HuBoard:

And as at time of writing this post, haven’t had a reply. To me, if I’m going to trust a cloud service, I need to be able to understand what it will and won’t do with my data. A non-working privacy policy page on the main site is a BIG #fail. Then not to respond to someone @ mentioning your twitter handle is a mark of the kind of service that I might expect if I was a customer. Not great.

Edit: so none other than the founder of HuBoard reached out to me. Privacy policy is fixed. It looks pretty good too, most of it is in plain English not legalese. Guess timezones for USA meant they were sleeping. The founder reaching out, that’s pretty good customer service. These guys will hopefully do some great things!

 

Waffle

I looked at Waffle.io. Now bizarrely the thing that most scares me about that product is its price – $0. I’ve learnt, if I’m not paying $ for something, then I am the product. I’m not sure if Waffle.io is still in beta/investor funding and is happy running without making any money but perhaps just piling up the company valuation? This whole SaaS valuation model sometime confuses the crap out of me. When you consider that companies the size Workday have profit margins of -24% (I mean WTF ?) It’s quite conceivable that charging money right now doesn’t boost the value of the company as much as having more subscribed users. Still paying nothing for something just makes me want to look for the catch. But I couldn’t really find a catch (I imagine it won’t be free forever and that payment will be required soon, but if it’s in same sort of price point as HuBoard then this shouldn’t be an issue $24 a month to be productive is not that bad!)

Waffle has some feature that I thought were pretty good, but specifically I liked the “size” attribute for an issue. By using this I can ensure that for each stage of the Kanban there aren’t too many issues being dealt with. So it can be fine to have quite a few small issues, but having the same number of large issues could cause a problem.

waffle

 

at the top of each column was a counter showing the number of issues and the total size. Next to my lovely picture was a number showing what I thought the size of this issue was.

This functionality I like, it will help manage all the issues and ensure we’re not going crazy pushing so much to into testing without actually testing it.

It was also nice in Waffle to be able to see the number of comments an issue has – it’s often worth drilling into those issue that have a lot of comments, even if it’s not yet my issue.

However, compared to HuBoard the amount of information shown can result in a quite busy screen – for example from Waffle’s own GitHub repo…

waffle2

 

Personally, I didn’t mind the “noise” but others I spoke to thought perhaps the minimal style of HuBoard better. Since I often have so many labels that colour alone is going to be an issue, I think I prefer this layout.

In contrast to HuBoard the mobile interface is not at all responsive, you see the same site but just zoomed out so you can’t read anything. That said, pinch zooming and scrolling around on the phone isn’t hard, and it does give you a better perspective of how the lanes compare. I’m pretty sure that there is probably a better responsive layout that could be adopted. But compared to the rendering mess that happened in HuBoard when accessing from mobile, it was much easier to use the Waffle site.

Conclusion

You can probably see where I’m heading! I decided to go with Waffle for the moment, but I’ll keep an eye out for HuBoard. As with all these SaaS apps, iteration is the name of the game, and I’m sure that feature parity won’t be far off. Neither tool has an Android mobile app, but neither tool is very usable on a phone – so perhaps when one of them makes that leap it will differentiate itself. We shall see.

After I’ve been using Waffle for a while, I’ll perhaps write another post about “real life” experience.

Cheers!

 

 

Security in depth – or a bug waiting to happen? – CSRF protection on SAP Gateway

What's that - It's the dragon that guards the locked door, we feed people who ask silly security questions to it

What’s that? – It’s the dragon that guards the locked door, we feed people who ask silly security questions to it.

<rant>

So I’ve got my knickers in a twist again. Recently I was playing around with sending some OData to my SAP server when it refused me. Now, I didn’t like that, but at least it was kind enough to tell me why. Apparently I hadn’t fed it a CSRF token. OK, so I looked in the headers of the GET that did work, and lo and behold there was a CSRF token there. I fed that into the POST I was doing, and bingo it worked.

Now it seems to me that many many people have hit the same thing and found the same solution. Indeed, I asked around some people I knew and they told me: “Get over it Chris, it’s in the header of your GET, it lasts all session, just use it!” But me being me, no, I wouldn’t accept that!

Slight aside – they also mentioned “Damnit, I remember when that patch came in, it buggered up my custom Gateway app and I had no warning that it was coming, took me ages to figure out why it wasn’t working.”

 

So I thought – OK? Why? Why do we have CSRF protection in the first place, what on earth is it?

CSRF protection – Cross Site Request Forgery protection, according to the websites I read is supposed to protect against the case where unknown to a user a cookie in the browser used for authentication allows a malicious site to alter data on your system. (And in the case of gateway, your SAP system).

So to send a PUT or POST or DELETE (the verbs that can change data) from a browser without user knowing is going to involve 1 of 2 things.

a) An injection of HTML on the page adds either a form that is going to POST some data (typical type of attack  CSRF protects against) or a link e.g. img tag which GETs data.

b) An injection of some script, e.g. JS on page that is going to do the PUT/POST/DELETE

In the case of (a – POST) the payload will be malformed and Gateway isn’t going to accept that as valid OData – so no security worries anyway. And for (a – GET) CSRF protection isn’t even applied.

In the case of (b) well if I can embed JS, I can just as easily embed a GET pull the header and then do an update with the CSRF token. Indeed the sites that advocate for the CSRF token approach make it clear that it cannot protect you in the case you have malicious Javascript.

In the case that the script is running on a page from a different domain, then CORS will kick in and stop the access – but if somehow the injection is on my own domain, I don’t see how we’re protected.

So I was at a loss. What protection does CSRF actually offer Gateway?

I further researched:

There’s a great explanation, which does better than I have at:

Play Framework

It is recommended that you familiarise yourself with CSRF, what the attack vectors are, and what the attack vectors are not. We recommend starting withthis information from OWASP.

Simply put, an attacker can coerce a victims browser to make the following types of requests:

  • All GET requests
  • POST requests with bodies of type application/x-www-form-urlencoded,multipart/form-data and text/plain

An attacker can not:

  • Coerce the browser to use other request methods such as PUT and DELETE
  • Coerce the browser to post other content types, such asapplication/json
  • Coerce the browser to send new cookies, other than those that the server has already set
  • Coerce the browser to set arbitrary headers, other than the normal headers the browser adds to requests

Since GET requests are not meant to be mutative, there is no danger to an application that follows this best practice. So the only requests that need CSRF protection arePOST requests with the above mentioned content types.

Since Gateway does not support POST requests with bodies of type application/x-www-form-urlencoded,multipart/form-data and text/plain (or if it does there’s your problem right there!) there is no need for CSRF protection.

I then had a fun conversation on Twitter with Ethan

The great thing about chatting with Ethan is you always come out having learnt something.

He makes a good point, and I’ll paraphrase him:

“The best security is deep and many layered and protects not only against the things that you know may happen, but also against those that you’re pretty sure won’t.”

I was wrong –  “to send a PUT or POST or DELETE (the verbs that can change data) from a browser without user knowing is going to involve 1 of 2 3 things. With the third being:

An exploitation of a hitherto unknown browser bug that allows it.

So now I’m confused. Is it worthwhile implementing the hassle that is CSRF protection, including the potential slowdown in speed of response from the solution (a paramount concern in a mobile app) for a situation that might happen.

When I’m writing ABAP code, I’m happy to trade away performance of the code for ease of maintenance. I don’t use pointers (field symbols) to loop over data that I do not intend to change, because some fool could come along later and accidentally do just that. If I instead use a work area, there isn’t that risk.

So in some respects I already do work that makes the solution slower to ensure lower risk, so shouldn’t I just do the CSRF thingy?

However, it is the reason for the risk – I don’t trust that the people maintaining the code after I leave will understand what I have done in my implementation of CSRF protection and won’t make a mistake. Even if I’m using UI5 in my application to update my SAP system, will they remember to call the refreshSecurityToken method every time before a PUT, POST or DELETE? Will they test it? Will they let the session expire in the testing so that they actually need to call the refreshSecurityToken method? I really hope so, but I doubt it. I see applications going into error and data not being updated when it should have been, because of “needless” CSRF protection.

weighing Dodgy Code vs Browser Bug risks

weighing Dodgy Code vs Browser Bug risks

So what I see is this: Security in enterprise is paramount, Gateway is enterprise software, it needs to be secure. So SAP made it so, even if it hasn’t really made a big difference or fixed any known security holes. But, “just in case”. However, custom code (and even standard code 😉 ) will have bugs, ones that rely on sessions timing out are particularly hard to test and will get through. The risk to your Gateway based mobile app is greater by having CSRF protection enabled than it is to your data being maliciously hacked through zero-day exploits. But I guess it depends on what that data is 🙂 .

</rant>

OK, one final bit…

<rant>

Given that I might not actually be using my Gateway for a UI app but for machine to machine transactions, would it PLEASE be possible that if I provide a valid authentication header in the PUT/POST/DELETE that we ignore the CSRF thingy? If I can somehow come up with a valid auth header, then we aren’t protecting anything with a CSRF token, we’re just making transactions slower by requiring multiple round trips that shouldn’t be needed.

</rant>

I feel better now. 🙂

 

Read how this discussion unfolds over at SCN…

http://scn.sap.com/community/gateway/blog/2014/08/26/gateway-protection-against-cross-site-request-forgery-attacks#comment-611490

P.S. my last post from SCN comment thread as I think it’s an important summary:

The thing is, by not implementing CSRF protection, we aren’t making our services insecure. There are no known ways to use CSRF against Gateway currently.

There is the case of protection against unknown attacks, but is that worth the cost, risk, effort?

Not using CSRF protection does not mean you are making your service insecure. It just trading “just in case” against real life complexity, risk and cost.

Depending on the data concerned, that “just in case” might be worth it. It won’t always be.

Architects have a responsibility to their companies to balance these risks and decide. We have the responsibility to inform them clearly and not just pretend that security is the only and overwhelming factor to consider.

Sometimes we put security on a pedestal and everything has to be done to address it. But we should remember that everything should have a risk/reward curve and sometimes NOT coding for a security risk is actually less risk than coding for it.

 

 

Scaling or cropping profile images into circles when the source isn’t a square

WARNING CODE AHEAD

<geek>

It took me probably too long to figure out how to do this so I thought I’d share.

circles

To do this in a way that most browsers support wasn’t so obvious (to me).

in the end I did it by (approximately):

HTML

<div class="profile-image" style="background-image:url('profile-img1.jpg')">
 <img src="profile-img1.jpg">
</div>

CSS:

div.profile-image {
 width: 47px;
 height: 47px;
 background-repeat: no-repeat;
 background-position: center center;
 background-size: cover;
 overflow: hidden;
 border-radius: 23.5px;
 -webkit-border-radius: 23.5px;
 -moz-border-radius: 23.5px;
 box-shadow: 0 0 4px rgba(0, 0, 0, .8);
 -webkit-box-shadow: 0 0 4px rgba(0, 0, 0, .8);
 -moz-box-shadow: 0 0 4px rgba(0, 0, 0, .8);
 border-radius: 23.5px;
}
div.profile-image img {
min-height: 100%;
min-width: 100%;
 /* IE 8 */
-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=0)";
 /* IE 5-7 */
 filter: alpha(opacity = 0);
 /* modern browsers */
 opacity: 0;
}

The image tag is in there so it’s still possible for the user to interact with the image, i.e. save it if they want, but it is made see through.

So the user “sees” the background image which is positioned such that it covers the div, so all of circle will have content, and the middle bit of image will be shown. The circle is made by making the border radius half the width of the div.

The important bits were the “background-size: cover;” and the “background-position:center center;”

Obvious when you know how.

</geek> (as if!)

 

credits to : http://stackoverflow.com/questions/11552380/how-to-automatically-crop-and-center-an-image for the inspiration!