How to solve: Do the opposite of what's done with input type=file With input type=file, the script cannot write the value, and changing it to this from another type clears the value. With input type=password, have it so that changing it _from_ password _to_ another type clears the value, and so that the script cannot _read_ the value.
Right. That GET is required to be idempotent makes no difference in using it for deleting data. DELETE, after all, is also supposed to be idempotent. However, GET is also supposed to be "safe".
The software that we used in school isn't available any more. I can't get Becky any more (oops - looks like I can). That site advertises a "30 day free trial" but nowhere can I find what the price is for the full version.
You can't read your watch or use your calculator in the dark, can you? I can read my watch and use my gameboy (which you did not mention) in the dark. the gameboy is a GBA SP, by the way. works with or without the light on. Why isn't this technology used for computer screens?
If you look at a normal LCD screen, a backlight is almost always necessary, even in a well-lit office. For that matter, it's necessary even in direct sunlight (can just _barely_ make out the outlines of windows without it). Why is that, anyway? My watch, my calculator, my gameboy, don't have that problem. Is it resolution-dependent (the watch being 7-segment cells, the calculator being about 50dpi and the gameboy being maybe 180 counting subpixels)? Or is it some difference in how they're made?
Magnetic effects on CRTs at low levels did not cause a permanent effect, and even at higher levels [which wouldn't be corrected by the degauss button] you could carefully cancel it out.
to play the station jingle over three times over the song right over the catchy chorus. That's the worst of all - I still remember "Radio Now 93.1 ain't nothin but mammals"
You know, no-one's going to deny that the old Mac OS sucked. There's a reason they threw it away and moved to a unix-based OS. Adapting this rant to refer to a newer mac without even changing the PC it refers to is just lame.
As an IT Manager, i would be very worried about "paying someone" for a fix...it would have to be "somone" that I can take to court should their fix domore harm than good Right, just like how you can take Microsoft to court if their "hotfix" does more harm than good.
So what makes Windows suddenly relevant to us now? Who are all these "Mac users" clamoring for aberrations like "Macintosh Explorer"? Are these the same "Mac users" on VersionTracker writing glowing reviews of Firefox and Azureus? Who let them in, anyway? What's "Macintosh Explorer" have to do with Windows? Does Windows suddenly have a monopoly on the word "Explorer" now? And I know people have been wanting a tabbed Finder [which is basically the same need the program you linked seems to be designed to fill] for years.
"glowing reviews of Firefox" - well, maybe if safari had gotten a type-ahead-find feature sometime before version 3, among other things, people wouldn't want alternative browsers. And, again, what's Firefox got to do with Windows, other than the fact that it's a cross-platform program?
Azureus is a crappy program, but I'm not sure how you're connecting it with windows either - As for being "un-mac-like", sure it doesn't follow the human interface guidelines, but name a piece of Apple software that does. The human interface guidelines have been a dead letter ever since quicktime 4 was released.
You can't clean a compromised system by reinstalling the operating system over the existing installation. Again, the attacker may very well have tools in place that tell the installer lies.
How exactly are these tools going to start running, when the system is booted to the install CD rather than the hard drive? I mean, by that logic the attacker could have tools in place to tell fdisk lies, too, so the only option is to literally incinerate the disk and buy a new one. Unless the attacker managed to flash your bios, you're probably safe here. And if that did happen, then you're completely screwed.
Also, the issue of having tools to tell an antivirus tool lies is, again, much less of an issue if you boot from a known-clean CD rather than using it from the running compromised installation
You can't trust any data copied from a compromised system. Once an attacker gets into a system, all the data on it may be modified. In the best-case scenario, copying data off a compromised system and putting it on a clean system will give you potentially untrustworthy data. In the worst-case scenario, you may actually have copied a back door hidden in the data.
Again, once all that might be compromised is data, there's nothing there to tell lies to the antivirus software. A text file isn't going to somehow run executable code when you open it in notepad. (whether "untrustworthy data" is an issue depends on what kind of data it is and, for that matter, what kind of attack - that shiny new browser toolbar might be nasty, but it isn't likely to be all like "im in ur spreadsheets messin with ur numbers" - for that matter, the worst a virus is likely to do is destroy data in obvious ways, not mess with it in a way that you won't notice and will cause problems if you rely on it later. The article seems to be geared towards cases of actual human attackers, not virus/spyware/etc)
Re:Solution for phishing: two-way login.
on
Firefox Quickies
·
· Score: 1
If it's encrypted in a way that lets the user verify that it's really the bank that he's talking to, then what's the point in having "two-way login"? If it's not, then all of the above happens, over an encrypted connection between the customer and the thief, and another encrypted connection between the thief and the bank. I assumed you were proposing "two-way login" as an alternative to SSL, not something in addition to it that still won't help if the user doesn't care that the certificates don't match.
Re:Solution for phishing: two-way login.
on
Firefox Quickies
·
· Score: 1
That is a step-by-step recipe for the perfect man-in-the-middle vulnerability.
You give your password, He gives your bank your password, The bank gives him its password, He gives you the bank's password
Re:SOMEONE is a little sensitive.
on
Firefox Quickies
·
· Score: 1
It's not IE being insecure. It hands firefoxurl: urls off to firefox because firefox registered a URL handler, the same as it hands aim: urls off to aol instant messenger, irc: urls off to whatever IRC client exists that actually bothers to support that (i think mirc did at one point), etc. This is by design, and it's _not_ a bad design. It's the same flaw as the "shell:" url thing that affected firefox, only it's in the opposite direction - with shell: it was windows that provided an idiotic URL handler and firefox that you'd click on it from, here it's firefox providing an idiotic URL handler and you click on it from IE.
And in case the PP didn't get it, the iphone ends up as toxic dust because it is made of toxic dry materials. If you just put a piece of wood in, you'd end up with ordinary (not toxic) dust, and if you put spaghetti sauce in you won't end up with any kind of dust unless you use a lot less water than normal people do.
"fork while fork" won't have the exponential effect, since fork returns 0 (false) in the child process, terminating the loop and causing growth to only be linear. You'd need fork while true.
Slashdot Mirror
How to solve: Do the opposite of what's done with input type=file
With input type=file, the script cannot write the value, and changing it to this from another type clears the value. With input type=password, have it so that changing it _from_ password _to_ another type clears the value, and so that the script cannot _read_ the value.
Right. That GET is required to be idempotent makes no difference in using it for deleting data. DELETE, after all, is also supposed to be idempotent. However, GET is also supposed to be "safe".
I would like to congratulate Slashdot on not putting any spoilers in TFS.
I will, of course, not be reading the comments until this weekend.
I had a modem replaced and the new modem's config/info/etc pages would only work on IE. Why? Not any fancy javascript or bad css.
Pages were served with the Content-type image/gif. IE ignores the content type, firefox does not (and I can't find any way to make it).
Magnetic effects on CRTs at low levels did not cause a permanent effect, and even at higher levels [which wouldn't be corrected by the degauss button] you could carefully cancel it out.
Don't you mean the Dynamic DHCP Protocol?
I was replying to the comment my post was in reply to, not the main article. Geez, mod it off-topic if you have to, but save some for the GP.
You know, no-one's going to deny that the old Mac OS sucked. There's a reason they threw it away and moved to a unix-based OS. Adapting this rant to refer to a newer mac without even changing the PC it refers to is just lame.
That's bash, not perl.
ok, what about HTML 4.0, or HTML 5 when it's done, in an HTML 2.0 browser from earlier than that? Arguing based on mime type is a cheap shot.
"glowing reviews of Firefox" - well, maybe if safari had gotten a type-ahead-find feature sometime before version 3, among other things, people wouldn't want alternative browsers. And, again, what's Firefox got to do with Windows, other than the fact that it's a cross-platform program?
Azureus is a crappy program, but I'm not sure how you're connecting it with windows either - As for being "un-mac-like", sure it doesn't follow the human interface guidelines, but name a piece of Apple software that does. The human interface guidelines have been a dead letter ever since quicktime 4 was released.
That article goes a bit too far:
You can't clean a compromised system by reinstalling the operating system over the existing installation. Again, the attacker may very well have tools in place that tell the installer lies.
How exactly are these tools going to start running, when the system is booted to the install CD rather than the hard drive? I mean, by that logic the attacker could have tools in place to tell fdisk lies, too, so the only option is to literally incinerate the disk and buy a new one. Unless the attacker managed to flash your bios, you're probably safe here. And if that did happen, then you're completely screwed.
Also, the issue of having tools to tell an antivirus tool lies is, again, much less of an issue if you boot from a known-clean CD rather than using it from the running compromised installation
You can't trust any data copied from a compromised system. Once an attacker gets into a system, all the data on it may be modified. In the best-case scenario, copying data off a compromised system and putting it on a clean system will give you potentially untrustworthy data. In the worst-case scenario, you may actually have copied a back door hidden in the data.
Again, once all that might be compromised is data, there's nothing there to tell lies to the antivirus software. A text file isn't going to somehow run executable code when you open it in notepad. (whether "untrustworthy data" is an issue depends on what kind of data it is and, for that matter, what kind of attack - that shiny new browser toolbar might be nasty, but it isn't likely to be all like "im in ur spreadsheets messin with ur numbers" - for that matter, the worst a virus is likely to do is destroy data in obvious ways, not mess with it in a way that you won't notice and will cause problems if you rely on it later. The article seems to be geared towards cases of actual human attackers, not virus/spyware/etc)
So what do you propose to do after you log in twenty times in a month?
That doesn't run the child process as root?
If it's encrypted in a way that lets the user verify that it's really the bank that he's talking to, then what's the point in having "two-way login"? If it's not, then all of the above happens, over an encrypted connection between the customer and the thief, and another encrypted connection between the thief and the bank. I assumed you were proposing "two-way login" as an alternative to SSL, not something in addition to it that still won't help if the user doesn't care that the certificates don't match.
That is a step-by-step recipe for the perfect man-in-the-middle vulnerability.
You give your password, He gives your bank your password, The bank gives him its password, He gives you the bank's password
It's not IE being insecure. It hands firefoxurl: urls off to firefox because firefox registered a URL handler, the same as it hands aim: urls off to aol instant messenger, irc: urls off to whatever IRC client exists that actually bothers to support that (i think mirc did at one point), etc. This is by design, and it's _not_ a bad design. It's the same flaw as the "shell:" url thing that affected firefox, only it's in the opposite direction - with shell: it was windows that provided an idiotic URL handler and firefox that you'd click on it from, here it's firefox providing an idiotic URL handler and you click on it from IE.
And in case the PP didn't get it, the iphone ends up as toxic dust because it is made of toxic dry materials. If you just put a piece of wood in, you'd end up with ordinary (not toxic) dust, and if you put spaghetti sauce in you won't end up with any kind of dust unless you use a lot less water than normal people do.
What system is this that allows "nice" to raise priority for users other than root?
And, you do realize that "nice" with a positive argument lowers priority.
"fork while fork" won't have the exponential effect, since fork returns 0 (false) in the child process, terminating the loop and causing growth to only be linear. You'd need fork while true.