Comments for $Tony[] = new Tony();

Comment on Into the Cloud by tony

tony — Sun, 29 Aug 2010 15:18:59 +0000

This is a very good explanation on Cloud-based services that uses a very simple-to-understand terms and use case:

http://techportal.ibuildings.com/2009/03/31/php-and-the-cloud/

Comment on Code Assist and Completion From CI Model Files by LiangShing

LiangShing — Fri, 18 Sep 2009 07:08:02 +0000

Yup! It works with Zend too~! Nice one! heh

Comment on I’m Getting Spam Comments by liangshing

liangshing — Tue, 04 Aug 2009 03:11:26 +0000

haha.. i got 135 spam comments and counting………..

Comment on Secure Your Website Content!! by tony

tony — Wed, 15 Jul 2009 03:18:47 +0000

So they forgot that Google spiders cache websites, not just index them…?

Comment on Secure Your Website Content!! by yuit

yuit — Tue, 14 Jul 2009 18:42:15 +0000

Did you know that the Expoert Exchange issue is actually them trying to be smart, and trick users into visiting their site?
Basically, the way they operate is this:
a. Make the questions and answers index-able by Google.
b. Hope that people searching for a term like “How do I simulate inheritance in PHP” on Google would be directed to Experts Exchange, because google already indexed my content.
c. But hide the true content from users when they actually arrive at Experts Exchange, so that they end up signing up as members.

Sneaky, basically. Cos no one else would program their site to be only visible by spiders and not human readers unless you are doing something sneaky.

Comment on Getting a New Laptop for Work by yuit

yuit — Tue, 14 Jul 2009 18:37:57 +0000

Bought yet? I think the X200 will be a little more with the 9-cell battery. But it should give you 6+ hours of computing Almost whole day!

Comment on I’m Getting Spam Comments by yuit

yuit — Tue, 14 Jul 2009 18:35:44 +0000

Google is starting to index our blogs. And through google, the spam bots have found us too

Comment on Session Fixation Problem in PHP by yuit

yuit — Wed, 01 Jul 2009 08:12:40 +0000

2 cookies is an interesting idea. So one is generated by the PHPsessionID, another can be just a random 6 digit number, similar to the Unix process ID.

Comment on Session Fixation Problem in PHP by tony

tony — Wed, 01 Jul 2009 01:53:36 +0000

The issue is a fundamental issue in web technology, yes I did thought so. I’m not so knowledgeable in .Net or JSP, that’s why I write the case in PHP perspective. But according to VA team of Peppermint Lozenges client, their JSP applications are not vulnerable to this kind of attack.

To tie the sessions to IP addresses is not so perfect too, considering lots of clients might be behind a single proxy, or single IP address from their internet provider. Hence what Hsing suggested to me is to tie the session with:

Hash ( IP address + Browser user agent + another cookie + a salt )

“another cookie” is just yet another cookie set as additional verifier. This will make the attack more difficult, if not impossible. Hence the attacker must:

1. Somehow in the same IP address with the victim
2. Use the same browser user agent (or fake it)
3. Find out what’s the name and value of “another cookie” (using the same method used to get the Session ID cookie)

Its more difficult now, but definitely not impossible.

Comment on Session Fixation Problem in PHP by yuit

yuit — Tue, 30 Jun 2009 20:24:06 +0000

Hmm… correct me if i’m wrong, but this “session fixation problem” is really not a PHP issue fundamentally, but the nature of how the web has worked around its innately stateless nature, to introduce stateful transactions (look at the history of cookies, and why Netscape introduced it).
Does jSP or .NET actually manage sessions differently from PHP that makes them less vulnerable to this “fixation problem”? I don’t think so. Sessions are cookies and cookies are cookies whether it is generated by PHP or JSP or .Net.

All 3 options listed above are sub-optimal in my view…

I feel that the most logical approach to this is actually to tie sessions to IP addresses. Once you detect a change in the IP address for the same session, generate a warning to the end user, log him out, and log the message in a “security-error.log” file.

There will be additional overhead of getting your application to “watch” the ip address for every transaction, but I guess we can work out some optimisation for that …