In our previous blog post, we discussed a new project that had some complicated issues that resulted in us learning some good lessons. We weighed up pros and cons and decided to keep going.
Cross-Site Scripting (XSS) attack is one of the most important security risks in web applications described in the top ten OWASP. Find out more here!
First Things First
How to proceed in a scenario full of drawbacks? From unique customer requirements, a team with different skills, to a language barriers with the client. Well, the divide and conquer technique is, as usual, a good starting point. We classified the systems by type and started to think about how a PoC (Proof of Concept) could be done for each system. We had some 60% of the work in REST (REpresentational State Transfer) clients, and that was a blessing, it’s easy to hack an HTTP-based API, right? Well, the problem was that 90% of the functionality we have to cover was on the non-HTTP clients. In that category, we had legacy “monsters” like Oracle Web Form, custom Java Applets and even a Telnet proprietary mainframe client for a 1972 IBM 3270 server!!!
After setting up the environments (VM with windows as a guest, we use Linux hosts), dealing with system access (VPN, users, etc.), we started using some great old friends (tools) such as wireshark.org and telerik.com/fiddler to sniff the network traffic. We also ended up disassembling some JAR files, to finally make our way to understand some details and prove that it was possible to go with the “hacker” way that we had taken as the first choice, at the beginning of the project.
Technical Feat
Experience counts! We had been working as a team, building the new state-of-the-art provisioning suite of Intraway. As part of a larger group we have been in charge of the Operational Service System (OSS) real-time Network Element (NE) connector, that is capable of managing a large group of NEs from different suppliers, models, and versions. It’s a highly complex piece of software that is designed to understand provisioning orders in a custom in-house specification language (including scripting in JavaScript). This module supports classic network protocols like LDAP, SNMP. HTTP, Telnet, SSH, etc., all of which are controlled by an asynchronous network layer implementation. That allows freeing the CPU while performing I/O requests. It’s built on top of modern C++ libraries like Boost, and uses the Boost::ASIO library especially for asynchronous operations. This is our experience in Intraway for almost two years, for this new project; however, we have to be more flexible and fast, without losing the low-level I/O programming, so we choose to go with the brand new Node.js technology (nodejs.org). Node is a run-time environment for developing back-end applications, using a flavor of Google V8 engine (highly performance JavaScript execution), specifically designed for a consistent asynchronous programming model.
We then started developing middle-wares agents that connect input and output that is exchanged between our platform and the cheated back-ends. No hard CPU calculation on a complex algorithm is needed, so that is ideal for using Node.js. In Node you have only one mainstream process, without multi-threading at all, designed from scratch for non-blocking requests. Every operation ends in a callback that waits for its time to continue when the network response is available. Meanwhile, other requests are performed. Everything is simpler if you compare this with our robust connector solution, here we have a simple language, with a simple “syntax sugar” and a built-in garbage collector, with tons of libraries available (npmjs.com repository rules), without shared objects in memory or elaborated thread sync transactions.
It’s likely that in a near future if the kind of demo, or fully functional mock-up that we are building today shows it’s doing the right work, we will have to throw all the Node.js connectors to the recycle bin. And then, with a regular API integrate the project to our more sophisticated C++ connector. However, for the kind of things we have to prove right now for this potential Intraway customer, this was the optimal path. A traditional approach for a real-time high-performance connector would have been a waste of time at this first stage. Our NEs are the custom applications back-ends instead of usual standard Telecom industry used protocols. This has changed the whole perspective and initial scope of the project dramatically.
As developers, we hate to do repetitive tasks, so after being fully involved in the development of those flexible connectors, we find ourselves doing the same thing time after time as we go forward and deeper in the network hack. Thus, we decided to build a higher level of abstraction, a kind of framework over the current implementation that we have in order to generate a Node.js compatible code capable of replicating the action captured from the network sniffed dumps. We wanted to generate that code in the most declarative human-readable way possible. Some time was invested in this technique, especially for the applications that represent the most significant amount of work overall the integrations that we have. This was huge progress concerning work automation, leaving us time to focus on the unexpected things like problems with parallel requests, error path hooks, encryption issues, input data pitfalls, etc.
Unleash your Connector
Surprisingly, some of the legacy applications we are doing via this force brute integration are also being used by other Intraway clients. Those clients, persuaded by their need to automate some internal processes, that should be connected with a part of our products, are currently negotiating with us to include some of the connector frameworks we have been developing these months. So we end up discovering new markets for the company, solving a shared need between some industry clients.
When we first looked at this project, the first natural reaction for us was to hate it, for good reasons. But now that the project has been advanced significantly (not finished yet), I think things have changed from our perspective. At the very beginning of the project, the company technology team also analyzed the effort to implement these connectors, and they concluded that there was a potentially infinite development cycle. We have realized that this is currently a fact. However, with those tools we have built now, it’s a simpler task to add new actions, or change things to adapt in case of any changes the applications owners could publish, assuming worst scenario because all hacked applications are legacy systems.
After more than a decade in this profession, I have frequently seen the need to make that shortcut, that hack, that workaround, that is probably not the most elegant solution ever but is the only way to achieve your goals inside a specific context. Sometimes, it is impossible to change, or at least difficult to change these sort of situations (more political than technical) in the short-term. That is the real world, and those are the kinds of things that you are going to learn by practice, not in a classroom.
I’m proud of being part of such a talented team that makes the grass grow in the desert. For us, programmers or technical gurus, sometimes it is inspiring to have a shocking event, which pushes you out of your limits and makes you think outside the box. In that sense, this project has all those ingredients to some degree, and I think that this is the kind of fuel that leads your imagination and creativity to top levels, allowing you to avoid routine and to truly enjoy the ride.
Further reading on security for web applications by reading our blog post Cross-Site Scripting Taken by Black box Testing
