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.
Freitag, 17. Oktober 2008
Mittwoch, 23. Juli 2008
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:
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.
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.
Dienstag, 6. Mai 2008
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.
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.
Freitag, 4. April 2008
Secure Software Applications - Today: Input Validation
Security assessments usually result in a lot of customer questioning and answering. It is just more efficient to just ask the right questions to the customer than looking up the information in documents or reading large amounts of source code. We have a set of questions that we usually ask a customer at the start of any security assessment.
One question is about input validation, which is one of the cornerstones of security application design and implementation. As an example, a credit card number solely consists of a fixed amount of digits in the range from zero to nine. There is really no reason for a software application to continue processing unless the user filled the credit card form field with the proper amount of digits. Other characters than digits must not be allowed. Performing strict input validation will greatly enhance the security of the software application.
In reverse, not performing strict input validation is a good indicator that the application has software bugs. This is why we ask customers where and how they perform input validation in their software applications. Not performing input validation is common, but one answer of a customer brought it straight to the point:
"The user is responsible for valid input. Are there any risks with that?"
Back in 2004, the risk related with that made in to the top of the OWASP Top 10, a hit list of the most exploited security vulnerabilities. So the answer is "Yes! There is a risk." Missing input validation does not directly result in exploitable security vulnerabilities. However, the most critical security issues such as Cross Site Scripting, Buffer Overflows, and SQL-Injection may result out of it.
Take an analogy:
If a bank employee said: "We neither have a vault, nor do we close our doors in the night. It's the people's responsibility to not steal the money.", would you entrust your money to this bank?
Key take-aways:
Security risks don't emerge solely through coding errors. Performing input validation is a requirement and should be integrated into the application's architecture.
One question is about input validation, which is one of the cornerstones of security application design and implementation. As an example, a credit card number solely consists of a fixed amount of digits in the range from zero to nine. There is really no reason for a software application to continue processing unless the user filled the credit card form field with the proper amount of digits. Other characters than digits must not be allowed. Performing strict input validation will greatly enhance the security of the software application.
In reverse, not performing strict input validation is a good indicator that the application has software bugs. This is why we ask customers where and how they perform input validation in their software applications. Not performing input validation is common, but one answer of a customer brought it straight to the point:
"The user is responsible for valid input. Are there any risks with that?"
Back in 2004, the risk related with that made in to the top of the OWASP Top 10, a hit list of the most exploited security vulnerabilities. So the answer is "Yes! There is a risk." Missing input validation does not directly result in exploitable security vulnerabilities. However, the most critical security issues such as Cross Site Scripting, Buffer Overflows, and SQL-Injection may result out of it.
Take an analogy:
If a bank employee said: "We neither have a vault, nor do we close our doors in the night. It's the people's responsibility to not steal the money.", would you entrust your money to this bank?
Key take-aways:
Security risks don't emerge solely through coding errors. Performing input validation is a requirement and should be integrated into the application's architecture.
Montag, 17. März 2008
Article: The Need for Measuring Software Security
Given the complex nature of modern software solutions, software testing is a crucial process step in the development cycle. Best practices in software testing are (more or less) standardized and supported with a variety of different tools. As a result, we see complex applications that can be used efficiently without failing too often. Furthermore, an experienced software tester is able to measure the quality of a software application and compare the results to other software applications.
Unfortunately, in our security assessments we often find reliable software applications that contain critical security vulnerabilities. In this article, Dr. Markus Schumacher and Sebastian Schinzel from Virtual Forge show an example of why security testing is that different from traditional software testing. Furthermore, the article shows Virtual Forge's approach to measuring the security of business software applications.
The article appeared in the first issue of Testing Experience, a new magazine that targets for professional software testers.
Unfortunately, in our security assessments we often find reliable software applications that contain critical security vulnerabilities. In this article, Dr. Markus Schumacher and Sebastian Schinzel from Virtual Forge show an example of why security testing is that different from traditional software testing. Furthermore, the article shows Virtual Forge's approach to measuring the security of business software applications.
The article appeared in the first issue of Testing Experience, a new magazine that targets for professional software testers.
Mittwoch, 20. Februar 2008
Vulnerabilities in Web Applications remain No.1
The annual Update to the SANS Top 20 list was published recently. This list compiles the top 20 security vulnerabilities in computer software per year. Web Applications stay at the pole position of the most common security vulnerabilities according to the SANS Institute (SysAdmin, Networking and Security).
The problem with Web Applications is that they have to be accessible from anywhere in the Internet. You cannot just secure Web Applications by telling a Firewall to filter out the bad guys because it is impossible to distinguish a normal user and a skilled attacker – you will inevitably fail.
The Web Applications itself must be air-tight when it comes to security. Unfortunately, preventing security vulnerabilities such as Cross Site Scripting (XSS) is not as easy as it sounds. In our security assessments, we regularly find XSS vulnerabilities amongst others in the target applications. And we find them within minutes after we get our hands on the customer's test system. Fixing XSS vulnerabilities is difficult as there seem to be many ways to mitigate the vulnerabilities for a developer layman. Unfortunately, only few of these ways fix XSS vulnerabilities once and for all. Others only prevent the proof-of-concept attacks that we communicate to the developers. This approach has the effect that slight modifications of the attack circumvent the alleged fix of the vulnerability. Our proof-of-concept attack does not work any more, but the vulnerability persists.
The key take away for you:
Certainly the most effective and efficient way to secure software applications is to bring in security experts right from start. This enables you to build your application on a secure foundation. Remember that you cannot test in security…
The problem with Web Applications is that they have to be accessible from anywhere in the Internet. You cannot just secure Web Applications by telling a Firewall to filter out the bad guys because it is impossible to distinguish a normal user and a skilled attacker – you will inevitably fail.
The Web Applications itself must be air-tight when it comes to security. Unfortunately, preventing security vulnerabilities such as Cross Site Scripting (XSS) is not as easy as it sounds. In our security assessments, we regularly find XSS vulnerabilities amongst others in the target applications. And we find them within minutes after we get our hands on the customer's test system. Fixing XSS vulnerabilities is difficult as there seem to be many ways to mitigate the vulnerabilities for a developer layman. Unfortunately, only few of these ways fix XSS vulnerabilities once and for all. Others only prevent the proof-of-concept attacks that we communicate to the developers. This approach has the effect that slight modifications of the attack circumvent the alleged fix of the vulnerability. Our proof-of-concept attack does not work any more, but the vulnerability persists.
The key take away for you:
Certainly the most effective and efficient way to secure software applications is to bring in security experts right from start. This enables you to build your application on a secure foundation. Remember that you cannot test in security…
How OWASP changed the security rules overnight
Companies become increasingly aware of business risks related to application vulnerabilities. However, application security is a very difficult field. As a result, most companies have little or no expertise with it. Unfortunately, if you have little or no expertise with any given topic, it's difficult to define a sufficient set of test cases. As a result, companies tend to use "Top X" vulnerability lists of platforms like OWASP, WASC, The SANS Institute and others. One advantage of this approach is that those lists appear to be best practice as they are publicly made available by independent organisations that are dedicated to this area. And they are a best practice, since those vulnerabilities are so common they are the absolute minimum requirement for testing. Unfortunately, hackers don't care which attacks are listed and which are not.
Therefore, if companies focus too much or only on publicly approved top issues, they run inevitable into trouble, because they will miss risks that are slightly below the radar. You might now argue if companies violate their due diligence by only focusing on the most widespread risks. But in any way, ignoring certain supposedly lower priority attacks does certainly not make applications sufficiently safe. In turn, this invites hackers to focus on those "lower priority" attacks.
Focusing on top vulnerabilities only has another adverse effect. What if the security organisation suddenly changes the attacks on the list you chose as a benchmark? OWASP did this in May 2007 by putting Cross Site Request Forgery (XSRF) on their Top Ten vulnerability list. All your past assessments and security guidelines become more or less invalid over night and your applications have to be re-tested for the most current list of top vulnerabilities. This is a reactive process and definitely not a best practice.
But how should companies address such a seemingly moving target?
In our experience, it's better to have security testers to prioritize testing activities by risks rather than by vulnerabilities. What matters to business, is that one supplier should not be able to see the prices of another (that is a business risk). If he gains this information through forceful browsing or command injection attacks is of little relevance. The risk is that confidential information is disclosed and not any specific method of attack. Therefore, companies should rely on a more general practice, both for external testing and for internal security guidelines. For external testing, they should define "risk cases" rather than test cases and focus their tests on them. No matter what and how attacks are ranked at any given time, the risks to the company usually remain the same. Testing according to a risk profile assures the security of your assets in a sustainable way.
For development guidelines, companies should focus on root causes rather than specific instances of attacks. Understanding root causes helps identifying attack variations and countering attack patterns in other contexts.
The key take away for you:
Of course, companies are well advised to make sure all attacks listed in the top ranks are covered by their risk mitigation approach. However, focusing solely on these is not enough!
In one of the next issues, we will talk about how to apply a risk profile driven approach for security testing.
Therefore, if companies focus too much or only on publicly approved top issues, they run inevitable into trouble, because they will miss risks that are slightly below the radar. You might now argue if companies violate their due diligence by only focusing on the most widespread risks. But in any way, ignoring certain supposedly lower priority attacks does certainly not make applications sufficiently safe. In turn, this invites hackers to focus on those "lower priority" attacks.
Focusing on top vulnerabilities only has another adverse effect. What if the security organisation suddenly changes the attacks on the list you chose as a benchmark? OWASP did this in May 2007 by putting Cross Site Request Forgery (XSRF) on their Top Ten vulnerability list. All your past assessments and security guidelines become more or less invalid over night and your applications have to be re-tested for the most current list of top vulnerabilities. This is a reactive process and definitely not a best practice.
But how should companies address such a seemingly moving target?
In our experience, it's better to have security testers to prioritize testing activities by risks rather than by vulnerabilities. What matters to business, is that one supplier should not be able to see the prices of another (that is a business risk). If he gains this information through forceful browsing or command injection attacks is of little relevance. The risk is that confidential information is disclosed and not any specific method of attack. Therefore, companies should rely on a more general practice, both for external testing and for internal security guidelines. For external testing, they should define "risk cases" rather than test cases and focus their tests on them. No matter what and how attacks are ranked at any given time, the risks to the company usually remain the same. Testing according to a risk profile assures the security of your assets in a sustainable way.
For development guidelines, companies should focus on root causes rather than specific instances of attacks. Understanding root causes helps identifying attack variations and countering attack patterns in other contexts.
The key take away for you:
Of course, companies are well advised to make sure all attacks listed in the top ranks are covered by their risk mitigation approach. However, focusing solely on these is not enough!
In one of the next issues, we will talk about how to apply a risk profile driven approach for security testing.
Abonnieren
Posts (Atom)