No. What makes this attack scary is that they can submit requests as you even without knowing your username and password.
Knowing the username and password is a separate way of using this attack, in which they trick you into (first) logging in and (then) doing the bad stuff.
This is one of the reasons that home routers, which often use HTTP Basic Authentication, are ironically more secure: HTTP Authentication pops up that annoying box we all hate. It's a pretty big signal that Something Weird Is Going On.
Almost any persistent authentication is vulnerable to CSRF. If it's a cookie, or HTTP Basic Authentication, or a server-side session that is assigned based on the client's IP address, in all those cases the server still sees the same browser with the same permissions doing the request.
For server-side session variables, how does the server know which session each user is part of? If it's a magic number ensconsed into every GET and POST, then a third-party form can't guess it. (Although putting that magic number into every GET means it's part of every URL, and URL's have a way of leaking.)
maybe the problem is, that a scripted POST should not be allowed.
I for one don't see a valid reason for the browser to allow a submit
method on forms with the method POST.
What's "a valid reason"?
We let JavaScript change the innerHTML of random form elements, reassign form actions, change URL's on the fly, make one button disabled when another checkbox is clicked. Maybe we can ask for the valid reasons for all those things.
We can't call this a flaw in JavaScript. If you were to block, say, submit() actions on POST forms, you would 1) break a lot of functionality on 90% of websites that have a function validate your form before submission, and 2) not solve the problem, because it wouldn't be that hard for someone skilled in JavaScript to work around that restriction.
You might ask "why are you allowed to submit forms to different URLs?"
The answer is because that's how the web was specified to work from the beginning.
In a way, the CSRF issue has grown because modern web-browsing includes multiple tabs and windows.
JavaScript really isn't at fault. I suppose you could try to make it such that JavaScript cannot do any events, but that would totally break GMail.
You can submit hostile forms without JavaScript, too. Just trick the user into clicking on a button that is actually the "submit" for your hostile form.
Slashdot Mirror
No it doesn't. There's no "software download" from the Sofaware site, the company that handles Check Point's SMB business.
If you have a Check Point product affected by this, it's probably already downloaded the 7.0.45x fix.
If it's the device I've heard about before, it tunnels the things you need through non-TCP protocols.
So, yeah, you don't need to open up *any* TCP ports. I'm not sure it buys you anything, besides the customer's ear for 2 seconds.
Knowing the username and password is a separate way of using this attack, in which they trick you into (first) logging in and (then) doing the bad stuff.
This is one of the reasons that home routers, which often use HTTP Basic Authentication, are ironically more secure: HTTP Authentication pops up that annoying box we all hate. It's a pretty big signal that Something Weird Is Going On.
See Drive-By Pharming at http://www.securityfocus.com/archive/1/460251 or the article linked from TFA, http://labs.calyptix.com/csrf-tracking.php
No, some others were fixed before the testing happened. CheckPoint was just the only vulnerable vendor to fix.
Almost any persistent authentication is vulnerable to CSRF. If it's a cookie, or HTTP Basic Authentication, or a server-side session that is assigned based on the client's IP address, in all those cases the server still sees the same browser with the same permissions doing the request.
For server-side session variables, how does the server know which session each user is part of? If it's a magic number ensconsed into every GET and POST, then a third-party form can't guess it. (Although putting that magic number into every GET means it's part of every URL, and URL's have a way of leaking.)
What's "a valid reason"?
We let JavaScript change the innerHTML of random form elements, reassign form actions, change URL's on the fly, make one button disabled when another checkbox is clicked. Maybe we can ask for the valid reasons for all those things.
We can't call this a flaw in JavaScript. If you were to block, say, submit() actions on POST forms, you would 1) break a lot of functionality on 90% of websites that have a function validate your form before submission, and 2) not solve the problem, because it wouldn't be that hard for someone skilled in JavaScript to work around that restriction.
You might ask "why are you allowed to submit forms to different URLs?" The answer is because that's how the web was specified to work from the beginning. In a way, the CSRF issue has grown because modern web-browsing includes multiple tabs and windows. JavaScript really isn't at fault. I suppose you could try to make it such that JavaScript cannot do any events, but that would totally break GMail. You can submit hostile forms without JavaScript, too. Just trick the user into clicking on a button that is actually the "submit" for your hostile form.