Posts Categorized: Security

Hacking SAP HANA Web Sockets

Disclaimer: This is not a production or documented feature – its also more of a hijack than a hack 


I have been hoping for the inclusion of Websocket support on the HANA DB platform for a while now, and I was a little disappointed it was not packaged in the SPS08 release. My goal when building apps (or products) is to make use of the core platform its running on as much as possible, I firmly believe that when convincing an IT department, or company, to implement a product or app, the first question is: “How much infrastructure does this need?”. This can often be a deal breaker and why I am such a big proponent of the HANA’s DB + XS App Server integration – it consolidates the requirements into a single investment. Having a Websocket technology built directly in XS can be an additional selling point which developers are starting to expect these days.

A little while ago I wrote a blog post on building a dashboard using the awesome Node.js package from Holger Koser, however I have really been wanting to use Websockets in the metric² platform since the get go. Some comments here and here are prime examples of my long lasting hope of seeing the technology being included in the XS Engine platform sooner rather than later. I recently had a little nudge again from John Patterson to dig back into the topic and did manage to hack something together. The most interesting part of this was that once I had it working, I was left wanting just a little more …

Firstly a little bit about Websockets and why I feel they important to the app/web development world …

Real-time: In the age of having blazingly fast DB’s, we need a UI & server side (In our case XSJS files) integration layer which can display the data to user with as little over head as possible. Web Sockets supports this by providing a low-latency, near real-time connection between a client and the server.

Light Weight: Currently we need to do multiple AJAX calls to our backend server (to the XSJS files) to either perform some complex logic or DML against our database. This is slow and also fairly network intensive as each request (and response) requires additional handshakes and the packet size is considerably larger than just the intended content inside the package. In Web sockets, the requests and responses are really just the content themselves.

Duplexity: Web Sockets by nature are Full-duplex, implying that we can send and receive data at the same time for multiple requests.

Persistence: Web sockets provide a “open” connection between the server and client after the initial upgraded HTTP request handshake has been made. This lets us perform multiple server side requests using the same connection. This also lets the server initiate a response without needing a request from the client side.

The importance of these 4 factors to the web development world and to HANA XS specifically is that this is the missing link for us to take Web applications to the next level.

[Cross-domain support is another great feature!] In this example I was able to successfully have the HTML + JS file local to my PC and execute it against my HANA XSWS service (via a public URL).

— 07/25/2014 — Chris Paine made a good point on potential Cross-domain security issues (see below). Keep in mind that these files are secured just like any of the XS content files, e.g. as long as your folder has a authentication requirement it will persist to this XSWS file as well.

So onto the more interesting HANA specific parts …


I initially realized that HANA XS was using Web Sockets in SPS06, when for some reason the XS Engine debugger was not loading correctly due to my user missing some permissions. After searching through the XS code I came across the folder where the debugger was saved and it included a interesting file with the suffix of xsws i.e. XSWebService. After doing more digging I found that Websockets were being loaded in the WebDispatcher config file and I was confident I could find a way to start using it for app development.

After spending some time trying to create my own HANA package with these file extension types I realized that the name is somehow being filtered and only this file, and more specifically, in this location can be executed, otherwise the XS Engine passes back a 403 (forbidden) – I was a little disappointed but it didn’t discourage me … and I decided I would simply re-purpose my Debugger.xsws file for my own needs After a quick backup, I was ready to do some coding …

Essentially, a xsws file is just like any xsjs file, with the exception that it has some socket code returning the responses versus your regular xsjs file. You can do things like $.import for additional libraries as well as perform $.sql functions. Here is a small snippet from the code over on Github.


  1. $.ws.onmessage = function (evt){
  2.     handleIncomingRequest(evt);
  3. }
  4. $.ws.onerror = function (evt) {
  5.     $.trace.debug(“error on connection: “ + evt.message);
  6.     throw new Error(evt.message);
  7. }
  8. $.ws.onclose = function (evt) {
  9.     $.trace.debug(“connection closed, disabling debugger”);
  10.     debugObject.enabled = false;
  11.     throw new Error(“Close status “ + evt.code + “:” + evt.reason);
  12. }



And this is some of our Client side code making calls the xsws service:


  1. // Create a new WebSocket. This works fine
  2.   var socket = new WebSocket(‘ws://<ENTER YOUR HANA SERVER HERE>/sap/hana/xs/debugger/api/Debugger.xsws’‘xsCrossfire’);
  3.   // Handle any errors that occur.
  4.   socket.onerror = function(error) {
  5.     console.log(‘WebSocket Error: ‘ + error);
  6.   };
  7. // Send the message through the WebSocket.
  8. socket.send(message);

As you can see – the code and requests are very simple and straight forward, in fact to me they are a little easier than jQuery + AJAX.

One caveat I did find was connection persistence in the event you have an error on the server side, the socket connection can break, in this case you would need a error handling state that attempted a reconnect before submitting any new requests.

A quick screenshot of the running test app i developed and how the server is sending persistence frames pings/pongs to validate the open connection along with the client request and server response.

If you are interested in trying this out on your test or dev instance I have posted the code on Github. Follow these simple instructions to get up and running …

1.) Using the Web IDE, open SAP -> HANA -> XS -> Debugger

2.) Make a backup of the Debugger.xsws file or simply comment out the contents.

3.) Paste the code into the file from Github

4.) Create the Websocket.html file and paste the contents of the Github file

4.) Create the app.js file and paste the contents of the Github file

5.) Open the Websocket.html file and enter any SQL statement

(Be sure you have the debugger security role)

As you can see from the files, the required methods for web sockets are really at a minimum and barely get in your way at all.


At the start of the article I mentioned I was left wanting a little more … this was mainly because since I have been wanting Web Sockets for such a long time, I realized that using it , alone its not really enough. In order for us to really take XS Engine to the next level, we also need to consider a “Publish/Subscribe” feature and a server side timer feature.

The Pub-Sub approach would essentially allow us to push data from the server side, on a specific occurrence of an event, much like a DB trigger. If a new row gets inserted, push the new inserted record to the registered subscriber.

The server side timer feature would allow us to create a server side timer (similar to a xsjob) which would persist and execute the server side function every x secs/mins/hours.

Overall I am pretty impressed with the opportunities Web sockets will bring to the XS Engine. I am hoping they will be included in the next release.

A Proof of Concept: The social aspect of enterprise data

Something I truly enjoy about my job is that fact that I am given freedom to explore creative solutions to business challenges. Being in manufacturing and the extremely demanding automotive industry, we are consistently challenged to produce better product, at a lower cost and in a shorter time in order to maintain reasonable margins. We are often faced with implementing solutions which augment our manufacturing processes and enable production employees to have better insight to the products being produced which ultimately ensures better quality. Some of these solutions include real time production labeling (tightly integrated from PLC’s to SAP), On-line visual display of requirements and products being produced and even include metrics like OEE.

So with my latest project, I tried to take a slightly different approach to handling enterprise data and bring a social aspect to certain tasks which are automated, but end users have a vested interest in. Some of these include: Work Orders being completed, Purchase Orders being received (Incoming material), material being rejected in Quality Control, shipments leaving a plant, etc. Essentially it gives “office” users insight to “plant” functions in a aggregated “Just a FYI” type of scenario.

Example: As a purchasing manager, I might not need to know that a specific purchase order has just arrived, but at the same time it’s a spark that might influence a reaction which could be useful to others, for example, I might need to notify quality to approve the material, or maybe the materials are “Urgent” or “Hot” and we need to notify production who is awaiting its arrival. But in some ways, this solution also provides just that. The ability for production (in this case a person urgently waiting for a product) to also know what is happening around them to make informed decisions and in return make informed decisions to enable people.

In my quest to solve some of the disconnect we have among departments I decided to develop a small proof of concept which would aggregate all of this data into a status stream or twitter type feed allowing users to respond to the events. I named the app “ERP Tweet”, it was “Sweet” (SAP + Tweet) origionally but since the source of data is not only SAP it did not make sense 😉

General Concept

Use data originating in and around our plants, in SAP and supporting systems to be displayed in a consolidated “Open” view where users can get filtered, pertinent data which may affect their day to day actions and tasks to provide insight into their own and supporting departments.

Design Requirements

Use a web based interface with “feeds” of data being added (push via XMLRPC). The ability to follow only certain departments or actions (Data filtering). Data should be interactive i.e. Add comments, send notifications if needed or requested.

Prototype Design

After doing some custom development and a few early stage prototypes I decided to use PHP. I wanted a interface or language where multiple sources of data could be used and since we do not use EP in our company needed a basic platform to launch such a site. I also decided to use WordPress with a “social” plugin called P2. I created a small middleware application using SAP.NET Connector to pull data from SAP and other sources and push it into the “feed stream” at specific intervals.

So this might sound fairly far fetched and out of the ordinary, but after implementing a small pilot to around 10 users, people are finding the system quite useful. Below are some screenshots and annotations which might make the concept a little bit clearer after my ramblings above.


Here is a general overview screen displaying recent happenings in and around our facility. As you can see there are multiple “Feeds” coming from multiple sources including, Production Lines, Material Handlers, Quality Control, Receiving and shipping.

Comments can be added by users to express concern or simply make a remark about a specific event. In this case, checking for a UL certificate on the material. If a comment is added, all users who are involved would be notified via email that a new comment was added.

Each “feed” can be filtered so you can only view departments or data which is relevant to your needs.

How secure is your enterprise data?

A couple of months ago, we had an emergency meeting with our process control engineers concerned by the announcement of the “Stuxnet” virus, which targeted Siemens PLC’s. For those of you who don’t know what a PLC is, it’s essentially a PC used in industrial operations to control machinery on a production line, AC Systems, elevators and even used in amusement park rides, to name a few. Unlike a regular PC with a couple inputs (mouse/keyboard etc.) and outputs (display), generally PLC’s have hundreds of real-time input and output possibilities and often control physical objects like motors, actuators, hydraulics and solenoids. The target of the virus has not been confirmed, but after much speculation it was thought that it was targeting Irans nuclear power program. In a nut shell this virus has the ability to change process parameters and possibly cause major havoc. (Imagine overriding the temperature cut off controls in a reactor?).

Security in general has always been a priority for me, both hardware and software, but sometimes certain aspects are not always in the limelight, in this case a ERP platform. Does this make us ignorant? I hope not. We do user audits, external audits, strict quality control on custom code and a host of other quality and security related tasks to ensure integrity and access to the system is well controlled. SQL exploits are catered for, cameras in server rooms, firewalls and policies are in place. But the question should be … is this enough?

Lets put it into context what the general possible exploits are for a company like ours (Automotive Industry) : code vulnerabilities, data theft, trade secrets, malicious damage, financial manipulation and a host of others which could have a crumbling effect. In our line of business we know who our competitors are, we know what products they produce and since the its a fairly mature product line – have a reasonably good idea of what the margins are. Even in a somewhat “exposed” industry, if you had to take our ERP’s data and give it to our competitors – we would be in serious trouble, simply having our BOM’s siphoned could lead to trade sectrets being exposed, formulation and routings could be used to then copy and reproduce the products to compete directly. Purchasing data could be used for competition between suppliers, and a form of insider trading. All by simply “reading” the system. Lets not get into a malicious attack situation and things could go pear shaped very quickly.
SAP specifically have addressed this potential risk avenue and provided us with products like the SAP VSI Interface, but how many companies actually use it? The VSI is simply an interface and not a product, and allows companies like Symantec to produce products which have the ability to “scan” the system for potential threats and exploits. How does a virus scanner scan custom ABAP code if it has nothing to compare it to? How does the scanner know that this SQL UPDATE statement is not maliciously changing code willy-nilly? How does the scanner know that the non standard open port on the ERP system is for legacy system integration and not to a SQL updating command for changing vendors payment addresses to somewhere in Nigeria? – Far fetched I know ;). Hueristic scanning can potentially pick up unknown or variations of viruses based on statistical analysis, but is also fairly inaccurate when the virus utilizes unknown code. SAP recently started a “Patch Day” similar to Microsoft’s, where new patches are released on the second Tuesday of each month to combat these new threats.

Even if we do use a AV product and patch the system, what about groups such as the stuxnet crowd who can fly under the radar – for close to a year – before being detected are out there watching the “systems” every move. Coming from an architecture background, and being a bit of a rogue spokesperson for “open architecture”, SOA, ES and various other new wave technologies has made me think about the potential negative impact all this openess has created. Not only is all the openness a potential hole, but so are highly customizable systems like SAP in general. Mobile devices, which I am extremely fond of, are another potential gaping security risk. Since the recent Sybase acquisition Smart Phones/Mobile have been the hot topic, and moving forward, will be one of the new end users of the enterprises data. But aside from logical attacks, dont forget to think about the physical risks. Consider a SAP HR app running in multitasking mode on a iPhone 4, forgotten in a canteen. The screens blank but after some easy investigating some pretty sensative data is loose. What about the same situation and they forget a smartphone at the customer, showing our sales margins? Another great example was the early iPhone 4 debut thanks to a irresponsible apple employee.

Getting back to more sinister aspects … past SAP specific viruses have gotten their fair share of exposure. The last one (and only one?) I am aware of was in 2002 and went by the names SAP.VSoft.A, SAP.Willi.A and ABAP/Rivpas. This was simply a proof of concept and not even a major threat. You can read more about it the SAP Note 512595 (Login Required). I am fairly surprised that this is the only well known and well documented virus. Please comment if I am wrong?
So how can we prevent these types of situations? In my opinion, its impossible. Why? We dont have control of foundation level systems which ERP platforms interact with and rely on for functionality. Think about windows 49 patches due to be released on Tuesday – a new record by the way. But what we can do, is ensure that we have the right (QA) experts and systems in place to mitigate as much risk as possible. We have to work as a team to be responsible architects, admins and developers when evolving and expanding our systems to meet expectations. We also need to do strict source code reviews periodically. Lastly, we need to not cave into pressure from internal customers insisting that the data they need is a necessity without putting the right measures in place to ensure its integrity. SAP also making an effort by providing a host of security guides (Login Required) which can be reviewed and utilized to reduce the potential risk.

In wrapping this up, we all spend a considerable amount of time give the right data, to the right people and now in the right place. What about the potential for the wrong people in the wrong place?