Security in times of the crisis

In times of a world-wide crisis, people reconsider their IT investments. What’s a must-have? What can be postponed? What can be dropped? From a security perspective we say, that security continues to be a must have. Damage occurs whenever people neglected security. And the trend for criminal actions doesn’t go down due to a recession. On the contrary, your competitors take a strong line on your assets. Industrial espionage is a bigger threat than ever. Even internal people will try to take whatever they can in order to foster their advantage in market. Therefore, we recommend: investing in security is a must-have – especially in times of a crisis.

Also IBM States: Custom Developed Applications Pose Great Risk

IBM published its yearly X-Force report. The study verifies a fact that we often see in our security projects: Security defects in custom applications are not on the radar and represent great risk for companies.

"[...] Again, this figure does not take into account custom developed Web applications that may not have had any vulnerability testing and may never see a public vulnerability disclosure to notify the developer of a Web site about vulnerability issues and potential exploitation."

Virtual Forge recommends reading the entire report.


Of course, we also recommend testing custom developed applications regularly and systematically.

Testing for Security Vulnerabilities - What are the Standards?

In our projects we are often asked for standard lists of vulnerabilities. The rationale be-hind this question is to ensure that security tests follow industry best-practice. If you don't do this, liability discussions might follow.

For quite some time there are top lists of vulnerabilities that must be avoided in applications. Some focus only on Web applications (OWASP Top 10) and others are industry-specific (e.g. security standard of Payment Credit Card Industry (PCI) or FDA Part 11). The "TOP 25 Most Dangerous Programming Errors" compiled by CVE/SANS is one of the most comprehensive lists today. Review such lists carefully and ensure that well-known issues are addressed in your development projects. You should also ensure that your security tester of choice is aware of such benchmarks.

A final thought - focusing solely on these lists is not sufficient. It's important to extend such a list for dedicated environments like SAP applications. They have some very special properties and specific security demands that are not addressed by generic top lists of vulnerabilities.

SAP GUI Vulnerable?

Every once in a while we see public alerts about insecure SAP software. A recent example is a security alert that describes a vulnerability of SAP GUI. We like to highlight that SAP provides a dedicated list of recent security notes: We recommend to monitor this list carefully and implement appropriate countermeasures in a timely manner.

SAP TechEd Berlin in Retrospect

The Codeprofiler Team had a great time at SAP TechEd in Berlin. Announcing "The 1st security scanner for ABAP" we had many interesting discussions with developers and managers.

Managers like the idea of having transparency about security at the code level by clicking a button. The built-in "traffic light" reporting of Virtual Forge CodeProfiler perfectly fits into existing reporting paradigms.

On the other hand, developers like the level of detail provided by the Code Cockpit: CodeProfiler shows the affected lines of code and provides technical details and guidance on fixing the issues.

That way, CodeProfiler users

a) Know if there are issues and how many
b) Can prioritize which issues to address first
c) Get a clear picture how to get the security of their ABAP programs right.

We also had a developer from a code supplier at our booth. She asked "What’s now with my backdoors in the ABAP code?" – Sad news for her: CodeProfiler will identify such issues quickly and will help companies to enforce their security requirements in every outsourced development project.

Mastering SAP Technologies 2008

Seems like Doug, owner of Eventful Management, was fed up with Melbourne's rainy winter weather. Anyway, this year's Mastering SAP Technologies moved from Melbourne (where it took place in 2007) to the Gold Coast. Winter at Gold Coast is really more like a nice summer day in Germany. Blue sky, 25° Celsius, and hundreds of kilometers of beautiful beaches.

So people were in a good mood and the SDN networking meeting went very nice with Thomas Jung leading the discussions. One of the hot topics in the meeting was the future of the Business Server Pages (BSP) development at SAP. Even though WebDynpro is the successor of BSP, Thomas presented a view new things he developed in BSP.

BSP indeed is a nice way to develop Web applications with SAP technology. However, when it comes to security, a BSP developer has to actively do certain things to secure the Web application. The developer has to do input validation and output encoding manually. If the developer does not perform those measures at any place, the Web application may be vulnerable.

I got some feedback to my comments on BSP security during the SDN networking meeting. Some suggested to include real ABAP coding examples during my talk, which I did. Here is the source code of a very simple example of a BSP Web page:

<%@page language="abap"%>
 <html>
  <body>
    <% data: x type string.
     x = request->get_form_field( 'x' ).
    %>
    <a href="<%=x%>">Next</a>
  </body>
 </html>"

As the Web page prints user input directly into an HTML page without any Input validation and output encoding, the Web page contains a Cross Site Scripting (XSS) security vulnerability. Actually, I found this code online as an example for BSP coding.

To mitigate this security threat, you need to filter the user input by passing it to the ABAP function cl_http_utility=>escape_url. This is the only way to fix the XSS vulnerability without breaking the functionality of the code.

As the above coding renders user input into a hyperlink, the page also has a Cross Site Request Forgery (XSRF) vulnerability, which allows attackers to trick victims into making arbitrary (potentially malicious) requests to other Web pages. But that's a different story.

So are those SAP vulnerabilities? No, they aren't. BSP works similarly to Java Server Pages (JSP), or PHP. Both technologies suffer from the same quirks. If you want to stick to BSP, you have to do a lot of security homework to keep up with the hackers. Note, that by using WebDynpros, you have a lot less to worry about, but you still have to worry. ... but that's a different story.

Hygiene of Web Applications

Back in 1847, a physician called Ignaz Semmelweis was working in a Hospital in Vienna, Austria. During this time, 5-30 percent of the female patients in this hospital got infected with puerperal fever which is often fatal.

Semmelweis was performing a study where he compared physicians who washed their hands regularly with others that didn't. He made a ground-braking discovery: Women treated by the hand-washing physicians had only a 1-2 percent chance of getting infected with puerperal fever, whereas other patients still had a 5-30 percent chance. Semmelweis' experiment showed that increasing hygienic standards in hospitals can safe many lifes.

What is really interesting in this study is that most of the physicians ignored, rejected, or ridiculed Semmelweis for this conclusion. They simply could not believe that a simple thing such as hand washing could have such an enormous effect on patient's health. It took many years for the medical profession to realize that Semmelweis was right with his views that are taken for granted in today's hospitals. Today's physicians are taught during study that hygiene is a crucial part of their
profession.

I was wondering when such an learning effect takes place in IT. Currently, there is only a limited number of universities teaching IT Security and even fewer that teach secure application design and secure programming. As a result, university graduates will continue to produce insecure application designs as well as insecure coding. Some of them are lucky enough to get training in secure application development, others will learn it the hard way that secure development matters. Same as the physicians 160 years ago, today's developers answer to good advices such as input validation, output encoding, and security design that they don't have time for these things.

Maybe, at some day, we'll have mandatory IT security classes in university and people will shake their heads when they hear that in the old days most of the web applications on the Internet were vulnerable to security bugs.