Check 9 MSDN search redirects to Linux.org
-
I'm not exactly a MS-fanboy, and absolutely not a fan of IIS.. I'm currently writing this on an ubuntu-machine (not exactly a fan of ubuntu, but linux in general). *hiding behind the table, waiting for flaming* But I don't think this is an problem with IIS/Windows Server, rather a problem with the ASP.NET-application. The problem is "simply" that the webdevelopers have neglected to deal with user-input in a "correct" way (either due to ignorance/lack of knowledge or laziness). This has nothing to do with the platform(**)... (**) One could argue that ASP.Net-developers are lazy in general, and so this is a problem that comes with ASP.Net... But that would be like throwing stone in a glasshouse. / Christopher H., Webdeveloper (PHP/MySQL, C#/ASP.Net), application programmer (C#/.Net/Mono etc).
Why do as everyone else, When Everybody else does it.
modified on Saturday, December 27, 2008 12:42 PM
I think it's a damn shame that there are children who see it as sport to deface others work, so that we have to defend against them in even the most trivial of applications. I hope it turns out to have been a honey-pot trap, and the script-kiddies get a well deserved visit from the FBI. They deserve nothing but our scorn.
-
I think it's a damn shame that there are children who see it as sport to deface others work, so that we have to defend against them in even the most trivial of applications. I hope it turns out to have been a honey-pot trap, and the script-kiddies get a well deserved visit from the FBI. They deserve nothing but our scorn.
Rob Graham wrote:
I think it's a damn shame that there are children who see it as sport to deface others work, so that we have to defend against them in even the most trivial of applications.
Channel 9 isn't a trivial application, any more than CodeProject is. Playful defacing is a whole lot better than subtle, account-stealing script injection, especially on a site using Passport / Live ID (imagine if the defacement consisted of simply changing the "login" link such that it redirects users to a fake passport login page). As annoying as this Rowan kid's actions are, they serve a valuable purpose: i'll be thinking twice next time Channel9 asks for my credentials...
----
You're right. These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets.
-
I think it's a damn shame that there are children who see it as sport to deface others work, so that we have to defend against them in even the most trivial of applications. I hope it turns out to have been a honey-pot trap, and the script-kiddies get a well deserved visit from the FBI. They deserve nothing but our scorn.
Personally I rather "do it right" (and maybe be over precautious in some cases) everytime, than forgot to do it when I really need it... I think that in most cases it's better to disallow "everything" (as HTML i inputs) and then add exceptions. That makes for a better and more secure result (as I've guarded me for things that I might have forgot otherwise...). And for the term "script-kiddies" (which don't need to be children...), those "attacks" can be part in probing for larger problems. (I'm not trying to turn this into a programming thread...)
Why do as everyone else, When Everybody else does it.
-
I think it's a damn shame that there are children who see it as sport to deface others work, so that we have to defend against them in even the most trivial of applications. I hope it turns out to have been a honey-pot trap, and the script-kiddies get a well deserved visit from the FBI. They deserve nothing but our scorn.
Rob Graham wrote:
They deserve nothing but our scorn.
They keep those of us who are web developers honest. This particular injection seems harmless enough to be considered beta testing and not larceny. Isn't it the M$ way to release software and let the user community debug it? X| I wonder how long it will take them to figure out that they have been hacked. I'm not telling. I don't work for them. ;P
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopes -
Rob Graham wrote:
I think it's a damn shame that there are children who see it as sport to deface others work, so that we have to defend against them in even the most trivial of applications.
Channel 9 isn't a trivial application, any more than CodeProject is. Playful defacing is a whole lot better than subtle, account-stealing script injection, especially on a site using Passport / Live ID (imagine if the defacement consisted of simply changing the "login" link such that it redirects users to a fake passport login page). As annoying as this Rowan kid's actions are, they serve a valuable purpose: i'll be thinking twice next time Channel9 asks for my credentials...
----
You're right. These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets.
Fair enough.:rose:
-
Rob Graham wrote:
They deserve nothing but our scorn.
They keep those of us who are web developers honest. This particular injection seems harmless enough to be considered beta testing and not larceny. Isn't it the M$ way to release software and let the user community debug it? X| I wonder how long it will take them to figure out that they have been hacked. I'm not telling. I don't work for them. ;P
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopesIn general I agree with what you said. My only reservation, however, is that I don't really think displaying the vulnerability to the rest of the world is the right way to get it fixed. An email via the contact link would have been more appropriate, and would not have loudly advertised the site's bug to those who would use it silently for a less noble purpose. Perhaps the hacker tried the email route first, but I somehow doubt it. As Shog9 pointed out, it is in all our interests to have the vulnerability repaired, before it becomes used as a phishing attack, or is exploited for direct theft of Passport/ Live ID credentials.
-
In general I agree with what you said. My only reservation, however, is that I don't really think displaying the vulnerability to the rest of the world is the right way to get it fixed. An email via the contact link would have been more appropriate, and would not have loudly advertised the site's bug to those who would use it silently for a less noble purpose. Perhaps the hacker tried the email route first, but I somehow doubt it. As Shog9 pointed out, it is in all our interests to have the vulnerability repaired, before it becomes used as a phishing attack, or is exploited for direct theft of Passport/ Live ID credentials.
Rob Graham wrote:
I don't really think displaying the vulnerability to the rest of the world is the right way to get it fixed
Possibly not the best way but it might be out of frustation. I have heard of people contacting M$ and never hearing a reply. That is rude at the least and can lead to their not reporting defects in the future. They are, after all, going out of their way to inform M$ of something that should have been caught in system test by a professional tester who is getting compensation for their efforts. I don't know if this is what actually happened in this case, and from the way some of the other links have been hijacked I suspect it wasn't done this way. In the end it is not the hackers resopnsibility to report the defect, it is the responsibility of the software manufacturer to throughly test their product before they release it. I have programmed many workarounds for defects that should have been caught in system test, and, no, I don't notify M$ because I don't have the time to make up proper test cases, without compensation, and deliver what I am resopnsible for to people who employ my services, and do compensate me for my efforts.
Rob Graham wrote:
An email via the contact link would have been more appropriate, and would not have loudly advertised the site's bug to those who would use it silently for a less noble purpose.
As I have mentioned above I know of people who did report defects only to be ignored by M$. This could possibly be on the advice of corporate attorneys who fear that admitting defects will set them up for legal remedies from people who paid for the software. I have been advised by corporate lairs lawyers to that effect when working for a very large corporation.
Rob Graham wrote:
Perhaps the hacker tried the email route first
That is not known but I doubt it. Nobody is saying that this hacker is noble.
Rob Graham wrote:
As Shog9 pointed out, it is in all our interests to have the vulnerability repaired, before it becomes used as a phishing attack, or is exploited for direct theft of Passport/ Live ID credentials.
No argument there. I just don't have the time or inclination to pursue the issue. As I have mentioned before the search menu item isn't the only one that is hijacked and others are h
-
Rob Graham wrote:
I don't really think displaying the vulnerability to the rest of the world is the right way to get it fixed
Possibly not the best way but it might be out of frustation. I have heard of people contacting M$ and never hearing a reply. That is rude at the least and can lead to their not reporting defects in the future. They are, after all, going out of their way to inform M$ of something that should have been caught in system test by a professional tester who is getting compensation for their efforts. I don't know if this is what actually happened in this case, and from the way some of the other links have been hijacked I suspect it wasn't done this way. In the end it is not the hackers resopnsibility to report the defect, it is the responsibility of the software manufacturer to throughly test their product before they release it. I have programmed many workarounds for defects that should have been caught in system test, and, no, I don't notify M$ because I don't have the time to make up proper test cases, without compensation, and deliver what I am resopnsible for to people who employ my services, and do compensate me for my efforts.
Rob Graham wrote:
An email via the contact link would have been more appropriate, and would not have loudly advertised the site's bug to those who would use it silently for a less noble purpose.
As I have mentioned above I know of people who did report defects only to be ignored by M$. This could possibly be on the advice of corporate attorneys who fear that admitting defects will set them up for legal remedies from people who paid for the software. I have been advised by corporate lairs lawyers to that effect when working for a very large corporation.
Rob Graham wrote:
Perhaps the hacker tried the email route first
That is not known but I doubt it. Nobody is saying that this hacker is noble.
Rob Graham wrote:
As Shog9 pointed out, it is in all our interests to have the vulnerability repaired, before it becomes used as a phishing attack, or is exploited for direct theft of Passport/ Live ID credentials.
No argument there. I just don't have the time or inclination to pursue the issue. As I have mentioned before the search menu item isn't the only one that is hijacked and others are h
:rose: I think we are on pretty much the same page. Microsoft has the responsibility to set a better example than this.
-
:rose: I think we are on pretty much the same page. Microsoft has the responsibility to set a better example than this.
I am currently reading "Programming Microsoft ASP.NET 3.5" written by Dino Esposito and published by Microsoft Press in February of this year. Perhaps this book should be a holiday present and required reading for all ASP.NET developers there. BTW my current contract is developing a web site in Perl, JavaScript and ColdFusion for Apache servers so I consider the ASP.NET book recreational reading. :-D
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopes -
Rob Graham wrote:
I don't really think displaying the vulnerability to the rest of the world is the right way to get it fixed
Possibly not the best way but it might be out of frustation. I have heard of people contacting M$ and never hearing a reply. That is rude at the least and can lead to their not reporting defects in the future. They are, after all, going out of their way to inform M$ of something that should have been caught in system test by a professional tester who is getting compensation for their efforts. I don't know if this is what actually happened in this case, and from the way some of the other links have been hijacked I suspect it wasn't done this way. In the end it is not the hackers resopnsibility to report the defect, it is the responsibility of the software manufacturer to throughly test their product before they release it. I have programmed many workarounds for defects that should have been caught in system test, and, no, I don't notify M$ because I don't have the time to make up proper test cases, without compensation, and deliver what I am resopnsible for to people who employ my services, and do compensate me for my efforts.
Rob Graham wrote:
An email via the contact link would have been more appropriate, and would not have loudly advertised the site's bug to those who would use it silently for a less noble purpose.
As I have mentioned above I know of people who did report defects only to be ignored by M$. This could possibly be on the advice of corporate attorneys who fear that admitting defects will set them up for legal remedies from people who paid for the software. I have been advised by corporate lairs lawyers to that effect when working for a very large corporation.
Rob Graham wrote:
Perhaps the hacker tried the email route first
That is not known but I doubt it. Nobody is saying that this hacker is noble.
Rob Graham wrote:
As Shog9 pointed out, it is in all our interests to have the vulnerability repaired, before it becomes used as a phishing attack, or is exploited for direct theft of Passport/ Live ID credentials.
No argument there. I just don't have the time or inclination to pursue the issue. As I have mentioned before the search menu item isn't the only one that is hijacked and others are h
As someone who did test for Microsoft for a long time and still works in the QA industry, don't assume that a professional tester didn't find it. I'd be surprised if basic injection wasn't tested - it was a large segment of test when I worked in Microsoft.com's test organization several years ago, and I doubt it's any different over at MSDN. However, just because the test organization found the issue doesn't mean that it was decided to fix it. Just wanted to speak up for those who may not be at fault here. Test in many companies (and in some, but not all divisions at Microsoft) is often considered an advisory capacity, but the decision about the priority of the bug may actually be determined by the business folks. That's a horrible place for it to happen, since often the business team doesn't have the expertise to make that determination, but the business folks DO hold the purse strings. And, to be fair, it could be that for some reason it would have been very costly or counter-productive to fix it, or there may have been some reason why they chose to allow it. I saw all of those scenarios at one time or another, at one company or another. I'm not saying I agree with that, just pointing out that it's not fair to imply that the testers were at fault, necessarily.
Caffeine - it's what's for breakfast! (and lunch, and dinner, and...)
-
As someone who did test for Microsoft for a long time and still works in the QA industry, don't assume that a professional tester didn't find it. I'd be surprised if basic injection wasn't tested - it was a large segment of test when I worked in Microsoft.com's test organization several years ago, and I doubt it's any different over at MSDN. However, just because the test organization found the issue doesn't mean that it was decided to fix it. Just wanted to speak up for those who may not be at fault here. Test in many companies (and in some, but not all divisions at Microsoft) is often considered an advisory capacity, but the decision about the priority of the bug may actually be determined by the business folks. That's a horrible place for it to happen, since often the business team doesn't have the expertise to make that determination, but the business folks DO hold the purse strings. And, to be fair, it could be that for some reason it would have been very costly or counter-productive to fix it, or there may have been some reason why they chose to allow it. I saw all of those scenarios at one time or another, at one company or another. I'm not saying I agree with that, just pointing out that it's not fair to imply that the testers were at fault, necessarily.
Caffeine - it's what's for breakfast! (and lunch, and dinner, and...)
I do hope that they tested for this kind of things... What strikes me is that if this is a mather of money/resources/time, then they must be on a very strict budget... Such things like this should be taking care of with just one line of code(**). But it can be so that this was categorized in a larger groups of "small problems", that didn't seamed to be necessary to fix.. (**) In PHP there's a special function for this, I think there is something similar in ASP.Net, if there isn't, a simple Replace on the string should still be sufficient...
Why do as everyone else, When Everybody else does it.
-
As someone who did test for Microsoft for a long time and still works in the QA industry, don't assume that a professional tester didn't find it. I'd be surprised if basic injection wasn't tested - it was a large segment of test when I worked in Microsoft.com's test organization several years ago, and I doubt it's any different over at MSDN. However, just because the test organization found the issue doesn't mean that it was decided to fix it. Just wanted to speak up for those who may not be at fault here. Test in many companies (and in some, but not all divisions at Microsoft) is often considered an advisory capacity, but the decision about the priority of the bug may actually be determined by the business folks. That's a horrible place for it to happen, since often the business team doesn't have the expertise to make that determination, but the business folks DO hold the purse strings. And, to be fair, it could be that for some reason it would have been very costly or counter-productive to fix it, or there may have been some reason why they chose to allow it. I saw all of those scenarios at one time or another, at one company or another. I'm not saying I agree with that, just pointing out that it's not fair to imply that the testers were at fault, necessarily.
Caffeine - it's what's for breakfast! (and lunch, and dinner, and...)
ResidentGeek wrote:
As someone who did test for Microsoft for a long time and still works in the QA industry, don't assume that a professional tester didn't find it. I'd be surprised if basic injection wasn't tested - it was a large segment of test when I worked in Microsoft.com's test organization several years ago, and I doubt it's any different over at MSDN.
Things are worse than I imagined.
ResidentGeek wrote:
just because the test organization found the issue doesn't mean that it was decided to fix it.
WOW :wtf:
ResidentGeek wrote:
Just wanted to speak up for those who may not be at fault here.
I am sorry for assuming that the testers didn’t find the vulnerability. I wasn’t aware of the work environment. This is really worse than I could have imagined.
ResidentGeek wrote:
Test in many companies (and in some, but not all divisions at Microsoft) is often considered an advisory capacity, but the decision about the priority of the bug may actually be determined by the business folks.
Again I have to say WOW :omg:
ResidentGeek wrote:
That's a horrible place for it to happen, since often the business team doesn't have the expertise to make that determination, but the business folks DO hold the purse strings
Perhaps this is an argument for product liability in the software industry. If the cost of releasing a defective product was considerable there would be a different cost/benefit equation.
ResidentGeek wrote:
And, to be fair, it could be that for some reason it would have been very costly or counter-productive to fix it, or there may have been some reason why they chose to allow it.
How could it be counter-productive to fix an injection vulnerability. You are not being fair, you are being apologetic for people who are not treating others fairly.
ResidentGeek wrote:
I saw all of those scenarios at one time or another, at one company or another. I'm not saying I agree with that, just pointing out that it's not fair to imply that the testers were at fault, necessarily.
I feel sorry that you had to work under those c