Jun 20 2007
On Being Wrong
One of the biggest problems with being an arrogant sod is that sometimes I get over-confident and cocky. This becomes a particularly bad habit when I’m using that cockiness to inform other people; highlighted just this week by my script ‘analysis’ of LittleWallOButtons.
Unless I’m particularly unsure about whether or not I could be wrong, I don’t tend to physically exploit the scripts I’m reviewing. 9 times out of 10, an idiot could spot the mistakes I see/highlight and you don’t need to waste time entering in test data or code to know what you’re going to get back. On Monday, although I wasn’t that sure I skipped the testing in favour of being vague and using the words “probably”, “possibly”, “may”, etc.
On this occasion, I slipped up. I was asked to explain my theory, and while it sounded wonderful in my head, in practise it was not as easy to demonstrate. While I have had success in creating a PHP file masked as an image and executing PHP code (which is exactly what I said was possible), there is nothing inherently malicious about what I’ve been able to achieve so far. This means that, assuming all of my other tests and theories fail, I may have been wrong in labelling LWOB insecure.
If I am wrong, then this will be a lesson to be a little more vigorous when it comes to proving things to myself first, and I’ll update my Unsafe Scripts page to reflect that. Heyho, at least Lirae and I have learnt ten times more about CSRF attacks over the past couple of days than either of us knew beforehand!
Warning
This post is over 6 months old. This means that, despite my best intentions, it may no longer be accurate. Age, motherhood, experience, loss... these things have all changed me from when this blog was started back in the heady (ha) days of my youth.
As much as I would like to go back and edit 10 years of archives to provide an insight into the 'me' of now — to update coding snippets and revise website advice — it would probably take years to do so (by which point I'd have to start again!) This would defeat the point of keeping these archives anyway.
Please take these posts for what they are: a brief look into my past, my history, my journey.
26 Responses so far
-
Eh, it sucks being wrong. But as Grissom on CSI said… “I’m wrong all the time. It’s how I get to ‘right’.” So, if you can admit when you’re wrong, you can learn from it and it will help you be right in the future!
-
Warning: Potentially stupid question ahead. Proceed at your own risk… What are “CSRF attacks”??
-
Ian, I have no idea. But they don’t sound good!
-
@Ian: The CSRF bit stands for “Cross-site Request Forgery” – it’s quite a devious type of attack that would take me far too long to explain because I only just grasp what the concept is anyway. Your best is to Wikipedia it: http://en.wikipedia.org/wiki/Cross-site_request_forgery Incidentally, I sent an e-mail to one of the guys who writes at ha.ckers.org who basically pwn all life and know lots more about this sort of thing than me, and he confirmed that this sort of thing is possible and even provided me with a snippet of code, but it’s perl and I don’t do perl so I’m still a bit “is it or isn’t it?”
-
That sounds so complicated… Is it something we need to worry about? How often does it happen?
-
@Rachael: from the wikipedia article:
Although cross-site request forgery is fundamentally a problem with the web application, not the user, users can help protect their accounts at poorly designed sites by logging off the site before visiting another, or clearing their browser’s cookies at the end of each browser session.
It has happened to some huge sites like Amazon, Digg, etc. -
So I have to log out of amazon once I leave? I’m getting a bit confused… Sorry. Is there anything I need to be aware of that I need to do to protect myself? Or is it, say, Amazon and Digg that need to be worried?
-
Well, usually these things are fixed as soon as they’re discovered, but yes, really it’s Amazon etc that need to worry.
-
Jem was wrong? What next? Burning skies and boiling seas? Come on, more testing, prove it’s possible. ;-)
-
I’m writing a wordpress script at the moment. I was going to send it to you to see if you could exploit it (I have a habit of writing code that brings down governments). Now I think I won’t trust you, in the off chance I have I actually wrote amazing code ;)
-
Would this effect users of a WordPress who remain logged in after posting at their website then begin visiting other websites? If so, would the safe thing to do be logging out when I’m finished?
-
Theres alot of implied knolwedge with XSRF and stopping the attack is a piece of cake..again its the golden rule of validation ‘Never trust client side data…ever’. Avoiding this method of attack is as simple as having some kind of value placed within the application that is uniquely sent along with the request for whatever cookie based service e.g $secret=”h8fd81kfdjg”; if ($secret && $_SESSION['logged_in']) { // do stuff } unless the attacker can harvest that value then goodluck brute forcing it :)
-
the above should read: if ($secret == “h8fd81kfdjg” && $_SESSION['logged_in']) not if $secret… cos check for the presence alone isn’t failsafe at all. Me and my rush typing :(
-
@Ian Thanks for asking, I had no idea what it was either. Now I know also. Nobody is prefect Jem. Even you. Don’t hate me for it. If you were prefect, I would think something was wrong with you. ;)
-
Try this nifty php function: “exec();”, and that is all you should need if you can run code through the script.
-
I’m not worried! *isn’t worried*
-
You are still ahead of most people – at least you are willing to learn from your own mistake.
-
That’s exactly the reason why I don’t start e-drama… well not intentionally, anyway.
-
@Harkey: I’d probably avoid exec(); while it does offer some protection, it is still a function which can be a real bitch to fully secure. If there’s a way to avoid it, I’d take it. Not to mention the nature of the function on servers running one of the microsoft-family; it can get pretty resource intensive when used improperly. IME, the use of exec() and co. are only required if you are only useful for server administration purposes. Just my 2 cents though :)
-
It’s nice to know that some of you don’t know what you’re talking about. I’d use exec if I found a vulnerability in a script where code can be executed. Access to what is essentially a terminal really can’t hurt. The same could apply to wordpress templates. Figuratively speaking a malicious code designer could input code into a template and distribute it freely with exploits planted right into the template. Exec() would be useful in running commands to get you from A to B. Really interesting…
-
Jem:
Harkey, you’re the one who doesn’t know what you’re talking about: I don’t NEED to use exec to do the damage. Why not try actually finding and looking at the script, and actually researching into what *I’VE* been saying before spouting your mouth off about irrelevant crap.
NO one said exec() was NEEDED to do the damage. I was simply stating that in the same situation *I* would have used the function. To quote myself:I’d use exec if I found a vulnerability in a script where code can be executed.
I’ve attempted to look at both of these scritps, but they’ve been removed because of your efforts, which doesn’t make it at all helpful to anaylze the code. What I’ve said is not irrelevant crap, and it is useful to the conversation. If you feel otherwise, then you can choose to ignore the information I give you. No need to be rude. I was simply trying to input useful information, not to start something, but I’m sorry that I apparently have stepped on your toes Jem :-O -
I fail to see how you’re quoting yourself, when you’re ..well, not. You actually said:
Try this nifty php function: “exec();”, and that is all you should need if you can run code through the script.
as if I’d a) never head of exec() and b) needed your advice (I tend to ask people who’ve proved to me they know what they’re talking about if I need help) As forI’ve attempted to look at both of these scritps, but they’ve been removed because of your efforts
– you obviously didn’t look very hard because Link Up Free is here: phpwebscripts.com/free_scripts/link_up.html What you said is not useful to the conversation. It didn’t add anything constructive the discussion of CSRF, it didn’t tell anyone anything helpful and certainly didn’t “step on my toes”. If you expect me to be polite, don’t come to my blog insulting my visitors (and possibly me) by suggesting that they don’t know what they’re talking about. -
Martijn didn’t know what he/she was talking about. I was not insulting him/her or you, by simply pointing out the ineptitude of what appeared to be a less than informed comment. Simply by the way the statement was made it was clear that the subject was foreign to this visitor. I did quote myself if you refer to my previous comment maybe before my last, then I was quoting myself. So, well, I was quoting myself. Generally, “exec()” isn’t used, so many users haven’t heard of it, thus they are lead to make uninformed statements as to its use. I wasn’t advising you Jem, and furthermore I have absolutely nothing to prove to you or anyone else. I wouldn’t give you help even if you had asked, and I certainly wouldn’t have made any attempt whatsoever to prove anything to you. So keep that in mind. Thanks for the link. I’ll take a look at the code. I obviously didn’t look very hard, because my google abilities are not matched with yours. Also, seeing as I cannot contribute valid comments to this conversation, then I will discontinue any further comments on the matter. I made a comment that I sincerely felt was valid to what was being discussed. I considered the acknowledgement of exec to make the security hole seem even deeper, and certainly much more dangerous than it appeared to be at first glance. My apologies for getting off topic. Thanks for your help, ~Hark
-
@Harkey: I assure you that I am by no standards inept; I work with PHP security on a daily basis and have given a few POC’s in the Belgian scene about that topic as well. Not to mention I will be going up for my Zend PHP5 certification in a month. In any case, the comment I replied to was vague to say the least. However, this doesn’t mean that I was not correct. In general exec should be avoided for use in any production script. Few purposes require it. This also applies to eval(), passthru(), system(), etc. I do not know you and I do not know what you specialize in and as such I do not make false and rude assumptions about your abilities. I suggest you do the same for other people in the future as it may lead to awkward situations such as this.
-
At the peril of getting off topic once again. I must express my deepest apologies to you Martijn. Though I had no intention of insulting you, I obviously have, and I was certainly not allotted the authority to do such a thing. It appears my outright intentions came out eschew, and I do apologize for anyone I have offended as a result.
-
It’s cool. Don’t worry about it, Harkey :) Now let’s not spam Jem’s blog any further, before she bans both our asses, hehe.
