Linked by Thom Holwerda on Wed 20th Jun 2007 09:26 UTC, submitted by TB
Internet & Networking "Apple's Safari is making its way to the Windows platform with the serious intention of making a dent in the market. As brilliant as the people are at Apple, I can't help but laugh at their, to put it politely, delusion. Before I ramble on too much, here are my five reasons why Safari will fail on the Windows platform." My take: Safari on Windows isn't here to take over the Windows browsing market. It's here for the iPhone.
Thread beginning with comment 249310
To read all comments associated with this story, please click here.
Design flaw? NOT!
by Sabon on Wed 20th Jun 2007 16:34 UTC
Member since:

"The flaws were not all simple coding errors or buffer overflows. For instance, the URL handling exploit was simply a design flaw,"

It was a design flaw they wouldn't have been able to correct it so fast. Gee, it took them all of a day to totally redesign Safari for Windows and fix the flaw? Wow!!!

Give them a few days and they can fix all of Windows design flaw then too.

Reply Score: 1

RE: Design flaw? NOT!
by elsewhere on Wed 20th Jun 2007 19:35 in reply to "Design flaw? NOT!"
elsewhere Member since:

"It was a design flaw they wouldn't have been able to correct it so fast. Gee, it took them all of a day to totally redesign Safari for Windows and fix the flaw? Wow!!!

Safari was not properly parsing URLS which was allowing free access to URL handlers on Windows. Basically allows command injection into a URL if the miscreant knows what they're doing. It's a nice, old-school exploit that far predates Safari and has absolutely no business existing in an internet-connected application in this day and age, particularly one proclaiming security.

We're not talking about a coding error allowing buffer overflows or anything sophisticated, those can be difficult to track down and anticipate. Those, frankly, exist in virtually every complex software project. No, here we're talking about bad design. Of course it only took them a day to fix it. It was probably no more than a few lines of code, but that doesn't excuse them from not having it there in the first place. Had it been a coding error, it likely would have taken longer to track down, verify, fix and test.

Secure application design is a mindset. Part of it means anticipating the unexpected (hence parsing input fields for validity) and another part of it means learning from previously documented flaws, vulnerabilities and exploits. Apple did neither here, and this was but a single element of the entire application. In fairness, they probably made assumptions about how Windows handles things like protocol handlers versus OSX, but even if that's the case, it raises even greater concerns. How well do they understand the platform they're now developing for? Much of Safari's inherent security on OSX likely relies on OSX's inherent security, but they're playing in a different, and much rougher neighborhood now. Assumptions and preconceptions must be tossed out.

At any rate, my point was that if vulnerabilities, particularly design flaws, were identified this early after a claim of secure design, it does beg the valid question of what they consider "secure design" and what else is waiting to be found. Some of those buffer overflows were found using standard fuzzing tools that researchers use all the time when sniffing out exploits, are Apple's engineers aware that these tools exist? Even so, coding errors can be minimized but never eliminated altogether, yet design flaws are just bad design and can not be so easily dismissed, no matter how sweet the Kool Aid tastes.

Reply Parent Score: 3