CxThoughts

Directory Traversal (CWE: 22) is usually considered as a subset of Path Manipulation (CWE: 73).

Very often, when I give lectures about application security, I start with a path manipulation example.
I found that it is easy for developers to understand the risk posed by this attack, but it’s relatively complicated to avoid it correctly, so it gives a great background for discussing more complicated attacks.

Usually I begin with a short “hacking game” showing the following VB (6) example (assuming that the Filename and Ext variables are considered as user input)

if (ext <> “exe”) then
Open filename & “.” & ext for output as #1
print #1, “^ CxThoughts blog”
close
else
msgbox (”WOW! I found a hacker!”)
end if

Then I ask the students to fix the code so the following rules will apply:
1. The user should be able to create ANY type of file everywhere she wants, with the content “^ CxThoughts blog”.
2. Only .exe extension is forbidden, and an appropriate message should appear in case of hacking attempt.

Seems simple, ah?
Try to do it yourself, then try to break in, then fix, then break in again… it is not as easy as it first looks.
My guess is that it will be possible to hack into any of your solutions…
I am looking forward to read your comments

——————-

Recently I have encountered the following Java code, which should receive a full path name, and return only the filename (e.g. getFilename(”C:\try\temp.txt”) = temp.txt)

What do you think?

private String getFilename(String filepath)
{
String filename = filepath.trim();
int index = filepath.lastIndexOf(File.separator);
if (index > -1)
{
filename = filepath.substring(index);
}
return filename;
}

LDAP Injection (CWE: 90) is an attack allowing the attacker to modify LDAP queries.

Recently, I encountered a nice LDAP Injection - and I started asking myself why do we hear so little about such vulnerabilities?
I would expect the opposite.

This attack method is less known to developers than SQL Injection and XSS, and development platforms rarely supply methods for avoiding it, so if the application at hand has LDAP access it’s not unlikely to be vulnerable to this kind of injection.

I know - many times it is hard to find this and even harder to exploit, which is why many times these vulnerabilities are left uncovered by pen-testers and code reviewers - but I think it worth the effort as successful attack may lead to a complete system compromise.

What is your best practice to avoid LDAP injections in your development platform? How do you test for the existence of it in an application?

———————————————————–
Here’s a Java code I found that seems to be vulnerable. Is that so? How? Why/Why not?
How would you do it better?

// Assume that var1 and var3 are predefined consts,
// and var2 is assigned a value fully controllable by the user

env.put(javax.naming.Context.SECURITY_PRINCIPAL,
var1+”=”+var2+”,”+var3);
DirContext ctx = new InitialDirContext(env)

This is really funny!
I attended a presentation the other day. The presenter said that in order to avoid SQL Injection for string parameters, it is possible to double quotes.
For example:
string fix(string s)
{
return s.replace(”‘”, “””); // ‘ -> ‘ ‘
}

Let’s assume that’s fine.
Now he showed how to use it:

name = GetUserName();
pass = GetUserPass();
sSql = “SELECT count(*) FROM t_users WHERE name=’” + name + “‘ and pass = ‘” + pass “‘”;
sSql = fix(sSql);
execute(sSql);

And now the question for you - does fix work well? does the way of using “fix” is fine or is it hackable? how?

C’ya next time,
Maty

Welcome to my first blog entry.
I am really excited of sharing with you my thoughts on application security.

As application security professionals, we struggle everyday with plethora of terms and buzzwords.
So many terms, techniques and technologies - every vendor uses his own terminology and concepts. What’s important? What’s not-as-much?

After 10 years in the field, I realized that many questions are common and keep rising again an again; A community dealing with these questions will make sure that these questions are (hopefully) answered, or at least discussed to fully understand the pros and cons for each point of view - saving us all time when encountering them again.

In this blog I will share with you some of the questions and thoughts that are crossing my way as Checkmarx CTO; Feel free to add your own. I’ll will do my best to get these answered thoroughly.

I hope that each post will lead to an active discussion - which everyone in the community will benefit from.

It’s up to you to make it work!

Cheers!!

Maty SIMAN, CISSP
CTO, Checkmarx