We (and all of the other toolkits they reviewed) fixed hundreds and hundreds of bugs in the 11 months since the release of Dojo 0.3.1. Like all of the other (well written) toolkits they reviewed, we take stability and quality seriously. Sure it takes them a while to review stuff, and I understand that they have constraints of publishing on a dead-tree schedule. It's even valuable for them to outline the decision process, but the world (and the toolkits) have moved on since.
So the proposal here isn't really a set of widgets, it's a set of widgets and a new programming language?
Frankly, I don't see how you're gong to remove the need for a "script engine", since your XML/application parser is going to need to preform the job in exactly the same way as a normal scripting engine (parse, display, run). It _might_ have the virtue of being more readily able to use the data it is intertwined with. Your draft shows some of the kinds of sophistication in contextual awareness that would make this worthwhile, but you don't ever break out of the bounds of what's readily possible w/ ECMA Script, which begs the question: what's the point?
Worse, determining what is program and what is data becomes near impossible, if your examples are anything to go by.
So I guess my point is this: if you're not going to go any further than what ECMA Script + DOM already provide, why not just put the effort into a JS library that does what you want (which, incidentially, is where you are now)? I think you've got a really neat set of widgets going, but the comingling of data and markup in a way that makes their seperation near impossible is a major impediment to uptake. I strongly beleive that we need better ways to tie XML data to behavioural script, but I don't think that confusing the two is a fruitful way forward.
I think you're going to find out that developers at large aren't going to enjoy "programming" in XML. It is overly-verbose for anything but data and meta-data transfer (and many will argue that it's highly inefficient at even that). Programmers and you and I know them want their if statments to look as close to pseudo-code as they can get (hence we have Python and Perl). All of that said, your toolkit still hinges ona a glue language (JS) to make SVG (a declarative style language) even become a programming language in the first place. Therefor the dependency on JS doesn't go away at all. In fact, you've only made your programming environment even more brittle (what are the odds you'll get good debugging info from a dsvg environment?) while continuing to mix data and program in a way that has some deeply negative security ramifications.
So anway, even if Flash and SVG don't compete, dSVG turns SVG into a Flash competitor, except that it's a "complete xml solution from end to end". Frankly, I'm not sure what that buys you.
The point of CSS is to seperate style from structure, and the point of XML is to encode meta-data that would otherwise be lost. Unless you can make a compelling argument that scripting constructs are meta-data that should be encoded, I'm going to continue to have a very hard time buying that programming as such belongs in your markup as anything other than CDATA sections. Yes, it has semantic meaning, but not semantic meaning for data! XSLT treads this line pretty narrowly, and I think it winds up on the right side of the fence in most places, but it again suffers from all of the problems anyone else that tries to make imperative constructs out of markup winds up with, and that's not a good thing.
We doen't use column-based programming languages any more for a lot of very good reasons. Why would we ever want to return to their equivalent if it's only more verbose?
So we can put an XML stamp on it? What does that buy us?
Anyway, Flash and SVG+JS are competitors, Flash and SVG without scripting are not. End of story.
Using XML for procedural programing isn't new. ANT comes to mind. Unfortunantly it turns out it's a really crappy language to program in (overly verbose, etc...). It does, however, make a decent glue language for putting down the declarative portions of a GUI.
As for the usage of XML-ish markup to define widgets, that's also not really very new. XUL, GLADE, netWindows (my project) all come to mind. The problem is tying them to data and programatic constructs. It's nice to see you're taking a similar tack with your wiget set as we are, however I tend to think that the minute you start writing standards around your toolkit, you only decrease your room to improve in the future. The community, i hate to say it, really doesn't know what they want which is why innovation is so powerful. It takes independent thought and originality to come up with someone else's old hat, and it seems you have that in spades. The trick is to not imagine that the community at large is imbued with the same qualities. The world at large doesn't care. You have to reach people with a need for what you want to do. The are the only ones that really matter.
A small dev team of people that grok what you're talking about and are interested in assisting you in making things better is usually going to yeild significantly better results than throwing something to the winding and seeing what takes off. In the worst case, you've satisfied the needs of the people that have needs in the first place, which isn't a bad place to be (although it can surely be obscure).
Anyway, I'd like to talk with you more about your toolkit. Your email addr isn't in your profile, so you can reach me at alex@netWidows.org.
I dunno...I'd like to see it but I'm not hopeful that anything like it will show up in Safari 1.0. The JS debugger in KDE HEAD is primordial. It barely allows me to set breakpoints with any regularity, and it's introspection and exception reporting need a lot of work before I'll use anything but Mozilla for real JS debugging work.
That said, Konq 3.1 is an absolute joy from end users's perspective. Now if only the same could be said about support for those developing against it...
If you consider that the web is used for a lot more than academic papers in the year 2003, you'll be quite suprised to find that JavaScript w/ DOM bindings can be quite useful in helping to make web _application_ interfaces suck less. HTML makes an....um...interesting presentation layer for lots of stuff, application data included, but when you want to do something with that data, HTML's cracks start to show.
navigator.appName checking isn't portable, and it can be quite verbose (requires a check per browser per feature), whereas object detection (which is what they're doing here) allows you to detect whether or not a specific feature is supported without knowing what browsers support it.
Browser specific hacks are what got us into the document.all vs. document.layers mess in the 4.0 days anyway.
As for browser-specific-code WRT to the XML loading thing, there's little (if any) support for DOM 3 Load And Save (as there's no public spec yet), so executing conditional, browser specific code to get this functionality is necessaray. Mozilla has implemented the XMLHTTP object that first appeared in IE, and so it's kind of the defacto standard (similar to innerHTML, which would also go away with DOM 3 Load And Save), however creating these objects is different on the various platforms, and is again not standard.
Um, it's because Opera 6.x has no DOM support to speak of. V7 is showing real promise on the platforms it's available on, but the Opera 6 series is notoriously bad at anything that isn't straight-up HTML w/ CSS.
This article isn't bad, but it only scratches the surface of a lot of more insidious problems with all the browsers "tested".
For instance, no real differentiation is made between DOM 0, DOM 1, and DOM 2 style events and their setters. There's not even a whisper about mutation events. The section on "display" properties totally misses the related (and more useful) problems of using attribute getters and setters in the various browsers. Ever tried setting a div to have overflow="scroll" on Safari?
One last nit: does anyone else find it uber-annoying that ADC's articles don't have authorship attribution?
I'm one of the editors for the OWASP Guide project.
Just verified this problem and am taking it up with the authors of the Top 10. If this is indeed plagarism, it will not be taken lightly, as this document was not developed in the usual open development methodology all of our other projects use (CVS, public mailing lists, etc...).
data transfer over mud isn't new. The best oilfield services companies have been doing it for quite some time.
As for why they need to get data out, consider that when you're looking for oil, you need to figure out what the EXACT geological formations look like (in 3 dimensions) a mile or 2 underneath the surface of the earth. The more data you can get out of a hole about any number of factors (rock hardness, resistivity, etc...) at a known depth, the better your odds are of figuring out what's down there in the main.
Worse yet are the new Common Criteria specifications that most NATO nations are now using as a replacement to the Red Book ratings (C1, C2, etc..) is just as borked and un-objective as FIPS.
Namely, the Common Criteria simply specify that you must tell the certifying body what a system will do and then it must do those things. It'd kinda like the mess that is ISO-9000 that way. Worse yet, labs are paid not by the potential purchaser, but by the entity wishing to have something certified (same as FIPS). Certified products are then "acceptable" by all countries participating in the Common Criteria evaluation scheme, meaning that poor products that are certified have a higher likelyhood of doing more damage than FIPS certified products will.
It's available (and being developed) as DocBook. You can grab a copy and send me patches. Or you could join the project and help us out if you feel that strongly. Send me mail if you're interested.
Fuzzers, proxies, stupid apps, and the limited number of SQL dialects in use today make this attack not just theoretical. In theory, yes, there are a lot of variables in play, but the intelligent attacker can quicly whittle this down. Are they hosted on IIS? Yes? Then the odds are pretty high they're using MSSQL too. It's not rocket science (or skiddies wouldn't be the ones doing it).
SQL injection is only one problem, but the results of it's success (given the poor defensive posture of most web apps) are usually catastrophic. It's not the root cause of most problems, but it's something that we can't just ignore. Like it or not, it's dangerous. The authors of the Guide (myself included) would be remiss in not including it.
More generally, canonicalization of input and sanity checking external inputs is the root cause of most security problems (not just in web apps) today. Calling it "clever indeed" ignores the severity of the situation and the truly atrocious state of security (which directly is related to code quality) of most deployed apps.
We're not trying to be clever. We're trying to be practical.
I'm one of the people responsible for the Guide (editor, author, whatever you want to call it). This being the case, I'd like to clarify what we're saying there.
Those of us that do security for a living must understand that there is no such thing as "secure". There is only "secure against some class of attackers for some period of time". That's the best anyone (DOD included) can ever assure about a system. Take the example of a bank vault. Bank vaults are not un-assailable, nor are they designed to be. Instead, they are designed to withstand some form of attack for some period of time. There will always be some form of attack that will work against said vault, espically if what it's in the vault is valuable enough.
So what's a defender to do? First, those designing systems must realize that there will always be holes, and that designing those systems in ways that that minimize the impact of penetration of any layer is the only sane thing to do. Secondly, one must understand that it's not about making something "secure", it's about managing the risk involved in whatever enterprise you're about. There will always be risk, and the constant patch-and-pray cycle we see in computing is just validation of this principle. Instead of insisting that something be "secure", it's better that the risk/cost ratio for protecting that asset be favourable.
So can we commit to providing a silver bullet? It would be irresponsible of the authors of the Guide to do any such thing. Instead, we are attempting to present some strategies for understanding, quantifying, and managing risk.
If you're interested in helping out with the project, check out our SourceForge project page and drop me a line if you'd like to contribute or have suggestions or patches. The whole thing is now in DocBook format, so diff's are always appreciated.
I'm one of the guys running the project that's producing the Guide, and I can assure you that v2.0 will include language-specific examples and pitfalls.
the term "smart card" covers a wide class of devices from various manufacturers. The only thing that many of them have in common is the fact that they speak a common protocol (ADPUs).
As for smartcards being 'broken', only some smartcards are truly 'smart' in any sense, and these are the cards that are often used in security applictions for things like key management. There have been several attacks in the past few years against cards of this type, including power stepping under extreme cooling, electron microscopy attacks, as well as the traditional "shaving" attacks that allow attackers to reconstruct the inner workings of the card. All of these attacks now have suitable countermeasures. That's not to say that new attacks aren't discovered, but the smartcard industry is not in any way static, espically for high-margin security (JavaCard) cards.
As for not checking for authorization, the beauty of smartcards is that they can do MUTUAL authentication. Both the card and the reader (in this case, your CD drive) can authenticate each other and decide if an operation is appropriate.
From that standpoint, this is a really intriuging device, however the endemic problems with key distribution are going to keep it from being effective in any way whatsoever.
I am most curious to see how they opt to power the card. Since smartcards aren't self-powered, they usually draw power from the reader, but that's not feasible in this case. I can just see the trial transcripts now: "your honor, I own this data, but the battery died..."
That also provides an interesting set of new parameters for the smartcard to worry about (battery life, etc...) that might provide interesting avenues of attack. You won't even need to hack the reader to spike the power to the chip, just solder on some leads and go to town = )
Slashdot Mirror
Matt,
We (and all of the other toolkits they reviewed) fixed hundreds and hundreds of bugs in the 11 months since the release of Dojo 0.3.1. Like all of the other (well written) toolkits they reviewed, we take stability and quality seriously. Sure it takes them a while to review stuff, and I understand that they have constraints of publishing on a dead-tree schedule. It's even valuable for them to outline the decision process, but the world (and the toolkits) have moved on since.
Regards
I'm Alex Russell, Project Lead for Dojo,
We're obviously flattered that our little project got covered in DDJ, couldn't they have reviewed newer versions of the tools they covered?
So the proposal here isn't really a set of widgets, it's a set of widgets and a new programming language?
Frankly, I don't see how you're gong to remove the need for a "script engine", since your XML/application parser is going to need to preform the job in exactly the same way as a normal scripting engine (parse, display, run). It _might_ have the virtue of being more readily able to use the data it is intertwined with. Your draft shows some of the kinds of sophistication in contextual awareness that would make this worthwhile, but you don't ever break out of the bounds of what's readily possible w/ ECMA Script, which begs the question: what's the point?
Worse, determining what is program and what is data becomes near impossible, if your examples are anything to go by.
So I guess my point is this: if you're not going to go any further than what ECMA Script + DOM already provide, why not just put the effort into a JS library that does what you want (which, incidentially, is where you are now)? I think you've got a really neat set of widgets going, but the comingling of data and markup in a way that makes their seperation near impossible is a major impediment to uptake. I strongly beleive that we need better ways to tie XML data to behavioural script, but I don't think that confusing the two is a fruitful way forward.
Um, it does nothing you can't do with SVG+JS+DOM, since that's exactly how it's implemented.
As for a need for it, I think there _is_ a need for widgets in dynamic SVG apps, but I think that large portions of this spec are miss-directed.
a tarball would also be nice.
Gord,
I think you're going to find out that developers at large aren't going to enjoy "programming" in XML. It is overly-verbose for anything but data and meta-data transfer (and many will argue that it's highly inefficient at even that). Programmers and you and I know them want their if statments to look as close to pseudo-code as they can get (hence we have Python and Perl). All of that said, your toolkit still hinges ona a glue language (JS) to make SVG (a declarative style language) even become a programming language in the first place. Therefor the dependency on JS doesn't go away at all. In fact, you've only made your programming environment even more brittle (what are the odds you'll get good debugging info from a dsvg environment?) while continuing to mix data and program in a way that has some deeply negative security ramifications.
So anway, even if Flash and SVG don't compete, dSVG turns SVG into a Flash competitor, except that it's a "complete xml solution from end to end". Frankly, I'm not sure what that buys you.
The point of CSS is to seperate style from structure, and the point of XML is to encode meta-data that would otherwise be lost. Unless you can make a compelling argument that scripting constructs are meta-data that should be encoded, I'm going to continue to have a very hard time buying that programming as such belongs in your markup as anything other than CDATA sections. Yes, it has semantic meaning, but not semantic meaning for data! XSLT treads this line pretty narrowly, and I think it winds up on the right side of the fence in most places, but it again suffers from all of the problems anyone else that tries to make imperative constructs out of markup winds up with, and that's not a good thing.
We doen't use column-based programming languages any more for a lot of very good reasons. Why would we ever want to return to their equivalent if it's only more verbose?
So we can put an XML stamp on it? What does that buy us?
Anyway, Flash and SVG+JS are competitors, Flash and SVG without scripting are not. End of story.
Gord,
Using XML for procedural programing isn't new. ANT comes to mind. Unfortunantly it turns out it's a really crappy language to program in (overly verbose, etc...). It does, however, make a decent glue language for putting down the declarative portions of a GUI.
As for the usage of XML-ish markup to define widgets, that's also not really very new. XUL, GLADE, netWindows (my project) all come to mind. The problem is tying them to data and programatic constructs. It's nice to see you're taking a similar tack with your wiget set as we are, however I tend to think that the minute you start writing standards around your toolkit, you only decrease your room to improve in the future. The community, i hate to say it, really doesn't know what they want which is why innovation is so powerful. It takes independent thought and originality to come up with someone else's old hat, and it seems you have that in spades. The trick is to not imagine that the community at large is imbued with the same qualities. The world at large doesn't care. You have to reach people with a need for what you want to do. The are the only ones that really matter.
A small dev team of people that grok what you're talking about and are interested in assisting you in making things better is usually going to yeild significantly better results than throwing something to the winding and seeing what takes off. In the worst case, you've satisfied the needs of the people that have needs in the first place, which isn't a bad place to be (although it can surely be obscure).
Anyway, I'd like to talk with you more about your toolkit. Your email addr isn't in your profile, so you can reach me at alex@netWidows.org.
Regards.
I dunno...I'd like to see it but I'm not hopeful that anything like it will show up in Safari 1.0. The JS debugger in KDE HEAD is primordial. It barely allows me to set breakpoints with any regularity, and it's introspection and exception reporting need a lot of work before I'll use anything but Mozilla for real JS debugging work.
That said, Konq 3.1 is an absolute joy from end users's perspective. Now if only the same could be said about support for those developing against it...
If you consider that the web is used for a lot more than academic papers in the year 2003, you'll be quite suprised to find that JavaScript w/ DOM bindings can be quite useful in helping to make web _application_ interfaces suck less. HTML makes an....um...interesting presentation layer for lots of stuff, application data included, but when you want to do something with that data, HTML's cracks start to show.
http://netWindows.org/docs/round_trips.html
navigator.appName checking isn't portable, and it can be quite verbose (requires a check per browser per feature), whereas object detection (which is what they're doing here) allows you to detect whether or not a specific feature is supported without knowing what browsers support it.
Browser specific hacks are what got us into the document.all vs. document.layers mess in the 4.0 days anyway.
As for browser-specific-code WRT to the XML loading thing, there's little (if any) support for DOM 3 Load And Save (as there's no public spec yet), so executing conditional, browser specific code to get this functionality is necessaray. Mozilla has implemented the XMLHTTP object that first appeared in IE, and so it's kind of the defacto standard (similar to innerHTML, which would also go away with DOM 3 Load And Save), however creating these objects is different on the various platforms, and is again not standard.
Um, it's because Opera 6.x has no DOM support to speak of. V7 is showing real promise on the platforms it's available on, but the Opera 6 series is notoriously bad at anything that isn't straight-up HTML w/ CSS.
This article isn't bad, but it only scratches the surface of a lot of more insidious problems with all the browsers "tested".
For instance, no real differentiation is made between DOM 0, DOM 1, and DOM 2 style events and their setters. There's not even a whisper about mutation events. The section on "display" properties totally misses the related (and more useful) problems of using attribute getters and setters in the various browsers. Ever tried setting a div to have overflow="scroll" on Safari?
One last nit: does anyone else find it uber-annoying that ADC's articles don't have authorship attribution?
Hi,
I'm one of the editors for the OWASP Guide project.
Just verified this problem and am taking it up with the authors of the Top 10. If this is indeed plagarism, it will not be taken lightly, as this document was not developed in the usual open development methodology all of our other projects use (CVS, public mailing lists, etc...).
I'll keep this thread posted.
data transfer over mud isn't new. The best oilfield services companies have been doing it for quite some time.
As for why they need to get data out, consider that when you're looking for oil, you need to figure out what the EXACT geological formations look like (in 3 dimensions) a mile or 2 underneath the surface of the earth. The more data you can get out of a hole about any number of factors (rock hardness, resistivity, etc...) at a known depth, the better your odds are of figuring out what's down there in the main.
Worse yet are the new Common Criteria specifications that most NATO nations are now using as a replacement to the Red Book ratings (C1, C2, etc..) is just as borked and un-objective as FIPS.
Namely, the Common Criteria simply specify that you must tell the certifying body what a system will do and then it must do those things. It'd kinda like the mess that is ISO-9000 that way. Worse yet, labs are paid not by the potential purchaser, but by the entity wishing to have something certified (same as FIPS). Certified products are then "acceptable" by all countries participating in the Common Criteria evaluation scheme, meaning that poor products that are certified have a higher likelyhood of doing more damage than FIPS certified products will.
More of your tax dollars hard at work...
It's available (and being developed) as DocBook. You can grab a copy and send me patches. Or you could join the project and help us out if you feel that strongly. Send me mail if you're interested.
We've put a mirror up.
no, but OWASP is run off of donated hardware and bandwidth, so we have limited resources to deal with the likes of a slashdotting.
Fuzzers, proxies, stupid apps, and the limited number of SQL dialects in use today make this attack not just theoretical. In theory, yes, there are a lot of variables in play, but the intelligent attacker can quicly whittle this down. Are they hosted on IIS? Yes? Then the odds are pretty high they're using MSSQL too. It's not rocket science (or skiddies wouldn't be the ones doing it).
SQL injection is only one problem, but the results of it's success (given the poor defensive posture of most web apps) are usually catastrophic. It's not the root cause of most problems, but it's something that we can't just ignore. Like it or not, it's dangerous. The authors of the Guide (myself included) would be remiss in not including it.
More generally, canonicalization of input and sanity checking external inputs is the root cause of most security problems (not just in web apps) today. Calling it "clever indeed" ignores the severity of the situation and the truly atrocious state of security (which directly is related to code quality) of most deployed apps.
We're not trying to be clever. We're trying to be practical.
Hi,
I'm one of the people responsible for the Guide (editor, author, whatever you want to call it). This being the case, I'd like to clarify what we're saying there.
Those of us that do security for a living must understand that there is no such thing as "secure". There is only "secure against some class of attackers for some period of time". That's the best anyone (DOD included) can ever assure about a system. Take the example of a bank vault. Bank vaults are not un-assailable, nor are they designed to be. Instead, they are designed to withstand some form of attack for some period of time. There will always be some form of attack that will work against said vault, espically if what it's in the vault is valuable enough.
So what's a defender to do? First, those designing systems must realize that there will always be holes, and that designing those systems in ways that that minimize the impact of penetration of any layer is the only sane thing to do. Secondly, one must understand that it's not about making something "secure", it's about managing the risk involved in whatever enterprise you're about. There will always be risk, and the constant patch-and-pray cycle we see in computing is just validation of this principle. Instead of insisting that something be "secure", it's better that the risk/cost ratio for protecting that asset be favourable.
So can we commit to providing a silver bullet? It would be irresponsible of the authors of the Guide to do any such thing. Instead, we are attempting to present some strategies for understanding, quantifying, and managing risk.
HTH
We've got a mirror of the guide up (fat pipe generously donated by the wisconsin 2600 chapter)
If you're interested in helping out with the project, check out our SourceForge project page and drop me a line if you'd like to contribute or have suggestions or patches. The whole thing is now in DocBook format, so diff's are always appreciated.
I'm one of the guys running the project that's producing the Guide, and I can assure you that v2.0 will include language-specific examples and pitfalls.
the term "smart card" covers a wide class of devices from various manufacturers. The only thing that many of them have in common is the fact that they speak a common protocol (ADPUs).
As for smartcards being 'broken', only some smartcards are truly 'smart' in any sense, and these are the cards that are often used in security applictions for things like key management. There have been several attacks in the past few years against cards of this type, including power stepping under extreme cooling, electron microscopy attacks, as well as the traditional "shaving" attacks that allow attackers to reconstruct the inner workings of the card. All of these attacks now have suitable countermeasures. That's not to say that new attacks aren't discovered, but the smartcard industry is not in any way static, espically for high-margin security (JavaCard) cards.
As for not checking for authorization, the beauty of smartcards is that they can do MUTUAL authentication. Both the card and the reader (in this case, your CD drive) can authenticate each other and decide if an operation is appropriate.
From that standpoint, this is a really intriuging device, however the endemic problems with key distribution are going to keep it from being effective in any way whatsoever.
I am most curious to see how they opt to power the card. Since smartcards aren't self-powered, they usually draw power from the reader, but that's not feasible in this case. I can just see the trial transcripts now: "your honor, I own this data, but the battery died..."
That also provides an interesting set of new parameters for the smartcard to worry about (battery life, etc...) that might provide interesting avenues of attack. You won't even need to hack the reader to spike the power to the chip, just solder on some leads and go to town = )
How quickly they forget:
If you are forced to distribute the secret in an insecure way, the game's over. Better yet. it only takes one read to copy the data.
I guess it's a nice idea that just misses the point.
Most of us preferr to run or DBs on platforms that don't require reboots when the phase of the moon changes.