Misunderstanding JavaScript Hijacking
at 2007-08-12 15:10:20
Very recently there has been a new paper about what the authors call JavaScript Hijacking. It is about an analysis of several JavaScript frameworks for a cross domain data retrieval vulnerability through the usage of the <script> tag. The paper comes to the conclusion that in nearly all JavaScript frameworks that work with JSON encoded data, the data can be retrieved cross domain via the <script> tag.
While some might consider this news and others do not, the authors very clearly write in their paper that this kind of vulnerability is already discussed in several places. However some malicious bloggers (previous link was wrong) claim that Fortify claims to have found a new class of web-based attacks. Other bloggers, like Chris Shiflett
Ed Finkler discusses Month Of PHP Bugs
at 2007-08-12 15:10:20
Today I learned about a podcast interview of Ed Finkler one of the members of the PHP Security Consortium. I heard through the first 30 minutes and was kinda bored because it was not really about PHP Security but about educating PHP developers, which is a subtopic of PHP Application Security which itself is a subtopic of PHP Security. I already wanted to switch it off when at around 34:32 they started talking about the Month of PHP Bugs.
Well knowing that Ed Finkler is one of the PHP Security Consortium it was absolutely no suprise that his response was lacking any substance and was only colored by anti Esser propaganda. I liked his comment that I am not worth being talked about. As usual for members of the PHP Security Consortium he wants to convince the audience that I am a bad person, with the argument that I throw the principles of responsible disclo
The PHP 5 challenge
at 2007-08-12 15:10:20
During the month of PHP bugs several people changed their credo from: "there are no vulnerabilities in PHP" to "vulnerabilities in PHP are not important, just tighten your OS". Other claimed that you can not rely on safe_mode and that you can always use shell_exec() to execute everything on the system.
It is quite amusing how the "safe_mode is flawed by design" green card is nowadays used to deny the seriousness of local PHP vulnerabilities. Just because safe_mode was a bad idea this does not automatically made disable_function a bad idea. And yes disable_function is nearly always used. Admins forbid the usage of all kind of functions like ini_get(), phpinfo(), shell_exec(), popen(), ...
So here comes the challenge. Imagine a PHP 5.2.2 server with ALL builtin functions being disabled. The challenge is to write PHP code that executes any binary inside the /bin directory. According
Watching the PHP CVS
at 2007-08-12 15:10:20
One of the worst things in PHP security is the fact that vulnerabilities in PHP are usually patched in the CVS and then wait for months until they are disclosed to the public. Time enough for everyone to grab the fixes from CVS and develop exploits for the vulnerabilities. Therefore PHP vulnerabilities are usually already known to the bad guys for weeks or months when a new PHP version comes out and the public is notified about the vulnerability.
However sometimes even after a release the general public does not know about some vulnerabilities, because it somehow happens that they are forgotten to be mentioned in the release announcement. This happened before and has happened once again with the release of PHP 5.2.2
A while ago a bug in the mcrypt_create_iv() function was reported and fixed that c
OWASP Risk Evaluation
at 2007-08-12 15:10:20
When you read the OWASP risk evaluation standard carefully you might get as confused as I got. They estimate the risk by first estimating the likelihood and then estimating the technical and business impact. The estimation is done by assigning the numbers 0..9 to a number of factors.
So far so good. Most of it makes perfect sense, but I was a little bit confused about the following factor:
- Opportunity
- What resources and opportunity are required for this group of
attackers to find and exploit this vulnerability? No access or special
resources (0), limited access and resources (4), special access or
resources (7), full access or expensive resources (9)
According to this factor the likelihood of an attack increases when more access to the application and more expensive resources are required on the attacker's side. I dare t
|