Menu
▾
▴
owasp-input-api-developers — Developers for OWASP Input API's
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
(1) |
Apr
(26) |
May
|
Jun
(57) |
Jul
(22) |
Aug
(50) |
Sep
(14) |
Oct
(9) |
Nov
(4) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Gabriel L. <ga...@bu...> - 2002-07-08 21:28:53
|
On Sun, 2002-06-30 at 22:58, Mark Curphey wrote: > Please forward to the list if it doesn't make it though (not subscribed > and can't admin : raised support ticket) > > 1. I would be tempted to say something like "could be implemented by all > major languages". If you design it generic enough its a porting issue, > if you support them all then its an overhead ;-) yeah cop out I know but > you may thank me for being that devil in the future ;-) Right. Thats what I'm thinking. > 3. Maybe this should read extensible ? Right. Totally what I meant. -=gabe |
|
From: Mark C. <ma...@cu...> - 2002-07-01 06:13:35
|
Please forward to the list if it doesn't make it though (not subscribed and can't admin : raised support ticket) 1. I would be tempted to say something like "could be implemented by all major languages". If you design it generic enough its a porting issue, if you support them all then its an overhead ;-) yeah cop out I know but you may thank me for being that devil in the future ;-) 3. Maybe this should read extensible ? Other ideas ; Be easy for people to hand back extensions to the community Be well documented Over and out... Here's some thoughts on high level requirements for the filters project. I hope this can serve somewhat as an example, but also as a diving off place... 1. Support for all major web application development platforms This is really critical to be the security standard for web applications and also to be very complete. But, I think its also pretty important to highlight at a high level so that when we do designs we can do designs that facilitate development for the different platforms. By platforms I'm thinking J2EE/JSP/Servlets, ColdFusion, ASP, PHP, .Net, Perl, ... 2. Simple to use Security is hard to begin with, but forcing developers to jump through hoops isn't realistic given schedule needs, developers experience and knowlege, developer acceptance of the api, and such. Because of this, it really needs to be something that the developer can easily integrate into their application, and has some clear easy to follow steps to put it in in the right places to offer real security. 3. Flexible This one is somewhat in conflict with the one above, but I think we can remedy this in the design process by building mutliple layers that allow interaction in different ways. So, while I may want to just have something that will slide into to the development platform I'm using, I think I'd also like something I can put into a novel application that could be built from scratch or something that can be used with an application that is using http to do new and exiting things. Along the lines of the diff between http proper and http extended to handle WebDAV. 4. Safe This api should do what it says it should do and should be very clear about where it stops, so that I understand what I'm protected from and what I'm left to do on my own. When it says it protects from something, there shouldn't be a sneaky way around it. (in lot of ways this is really where I think canonicalization fits in...) 5. Complete It should offer tools and design patterns to help me build a totally secure web application. Where building generic tools to accomplish the job doesn't really fit, this api should allow me to enhance or extend it and in fact encourage me to so that my specific needs are met for enhancing security. For instance, in the case of data type validation. Suppose I have an ID parameter that is used to determine what document we are downloading from a dynamic web application. Some ids are allowed for some users and others are not... This is really a very common design pattern for web applications and a poplular spot for security problems. While its good for us to be able to validate at least that we are getting a numeric value, it would be really nice to be able to plug in acceptable values to custom code, a collection in the platforms session store, a (potentially cached) database query and so forth... I kind of feel like these things might be a little bit higher level then they should be, but maybe they will serve as a tool to get the ball rolling. -gabe |
|
From: Alex R. <al...@se...> - 2002-06-28 18:35:58
|
Gabriel Lawrence wrote: > Uhhh, am I too demanding to say how 'bout both? Darn, now I really sound > like a marketing guy ;-) I think that shooting for both is a poor idea for a first release because it will allow simply too many degrees of freedom, which we previously identified as a significant source of security failure. Building security software (espically when you are on the defense) is necessarialy _very_ different from building "regular" applications, and we need to modify our goals and evaluation criteria accordingly. -- Alex Russell al...@Se... al...@ne... |
|
From: Gabriel L. <ga...@bu...> - 2002-06-27 18:44:15
|
On Thu, 2002-06-27 at 08:00, Alex Russell wrote: > So, to clarify this, are we saying that the toolkit itself should be > flexible (allowing an arbitrarialy complex input syntax, etc) or are we > specifying that it should be atomic enough to be used in flexible ways? > I believe that the answer to this question lies a the heart at some of > our current dissagreement. > > So what do you guys think? Uhhh, am I too demanding to say how 'bout both? Darn, now I really sound like a marketing guy ;-) -gabe |
|
From: Gabriel L. <ga...@bu...> - 2002-06-27 18:43:08
|
On Thu, 2002-06-27 at 07:08, Chr...@ey... wrote: > Gabe, > > Hehe, maybe I have an incorrect understanding of what is meant by > requirements (a distinct possibility), but what you have below is what > imagined the Vision statement would be. I guess I always imagined > requirements as being specific statements of things a program must do, > e.g. "the program must core dump and cause the blue screen of death when > the user clicks the save button." Nonetheless, I like what you have > below, regardless of whether it is a set of requirements or a vision > statement. Yes you are totally correct. But after I wrote it and realized it was off topic, I still decided to send it ;-) Show no fear. > While I like some of the things you are saying in point #5, I have > concerns about some of the wording. For example, I thought the focus of > this project was writing an API for scrubbing user input, not creating "tools and design patterns to help me build a totally secure web > application". No application is totally secure, or ever has been, or ever will be. Sorry marketing speak. Some folks have actually accused me of being a marketing person in the past. I still claim I'm an engineer, but every once in a while things get flubbed up. What I'm really trying to get at is that using our api should be easy, but if designed well can also lead the developer to think about security as part of the development process. Not really a goal of the project, but I think a side benefit. > If what you are suggesting is that the API be extensible, that sounds like > a good idea on the surface, except that it is in direct conflict with > "simple". If we do not trust developers to use the API correctly unless > we make it simple, then what makes us think that they will extend the > framework without making it insecure in the process? Ahhh... Yes, I am aware the flexibility/extendability is often in conflict with simplicity. So I think two things are important. First, I like to set high goals and get as close as possible. I'm sure some amount of flexibility will be lost for simplicity and some amount of simplicity will be lost for flexibility - but lets not give up at the beginning. Lets shoot for something powerful. Also, if we take a layered approach to developing this we may be able to set it up so that there is a simple layer the most folks use and then a flexible layer that people who need/want to enahnce or extend what we are doing can use as well. Can we avoid the making it insecure in the process problem? I don't know. But what if they can make it more secure by doing something? Do we want to kill the ability to do that on the worry that someone will bungle things? Good questions that I don't know the answer to. I'm going to keep saying this, but I think layers are the secret. Layers that allow people to interact with what we are doing in different ways. From totally plug and chug to well integrated and totally interdependant... It does sound like this one is a bone of contention and I am willing to back off on the idea of flexibility/extendability for the first round at least :-) -gabe |
|
From: Alex R. <al...@se...> - 2002-06-27 15:00:27
|
Gabriel Lawrence wrote: > Here's some thoughts on high level requirements for the filters project. > I hope this can serve somewhat as an example, but also as a diving off > place... > I'm in total agreement with points one and two, but the next one concerns me. > 3. Flexible > This one is somewhat in conflict with the one above, but I think we can > remedy this in the design process by building mutliple layers that allow > interaction in different ways. So, while I may want to just have > something that will slide into to the development platform I'm using, I > think I'd also like something I can put into a novel application that > could be built from scratch or something that can be used with an > application that is using http to do new and exiting things. Along the > lines of the diff between http proper and http extended to handle > WebDAV. So, to clarify this, are we saying that the toolkit itself should be flexible (allowing an arbitrarialy complex input syntax, etc) or are we specifying that it should be atomic enough to be used in flexible ways? I believe that the answer to this question lies a the heart at some of our current dissagreement. So what do you guys think? -- Alex Russell al...@Se... al...@ne... |
|
From: <Chr...@ey...> - 2002-06-27 14:02:48
|
Gabe,
Hehe, maybe I have an incorrect understanding of what is meant by
requirements (a distinct possibility), but what you have below is what
imagined the Vision statement would be. I guess I always imagined
requirements as being specific statements of things a program must do,
e.g. "the program must core dump and cause the blue screen of death when
the user clicks the save button." Nonetheless, I like what you have
below, regardless of whether it is a set of requirements or a vision
statement.
While I like some of the things you are saying in point #5, I have
concerns about some of the wording. For example, I thought the focus of
this project was writing an API for scrubbing user input, not creating "tools and design patterns to help me build a totally secure web
application". No application is totally secure, or ever has been, or ever will be.
If what you are suggesting is that the API be extensible, that sounds like
a good idea on the surface, except that it is in direct conflict with
"simple". If we do not trust developers to use the API correctly unless
we make it simple, then what makes us think that they will extend the
framework without making it insecure in the process?
Just my 2 cents, for whatever they're worth.
Chris
owa...@li...
06/27/2002 12:34 AM
To: Owasp Filter <owa...@li...>
cc:
Subject: [Owasp-input-api-developers] My thoughts on requirements
Here's some thoughts on high level requirements for the filters project.
I hope this can serve somewhat as an example, but also as a diving off
place...
1. Support for all major web application development platforms
This is really critical to be the security standard for
web
applications and also to be very complete. But, I think its also pretty
important to highlight at a high level so that when we do designs we can
do designs that facilitate development for the different platforms. By
platforms I'm thinking J2EE/JSP/Servlets, ColdFusion, ASP, PHP, .Net,
Perl, ...
2. Simple to use
Security is hard to begin with, but forcing developers to
jump through
hoops isn't realistic given schedule needs, developers experience and
knowlege, developer acceptance of the api, and such. Because of this, it
really needs to be something that the developer can easily integrate
into their application, and has some clear easy to follow steps to put
it in in the right places to offer real security.
3. Flexible
This one is somewhat in conflict with the one above, but
I think we can
remedy this in the design process by building mutliple layers that allow
interaction in different ways. So, while I may want to just have
something that will slide into to the development platform I'm using, I
think I'd also like something I can put into a novel application that
could be built from scratch or something that can be used with an
application that is using http to do new and exiting things. Along the
lines of the diff between http proper and http extended to handle
WebDAV.
4. Safe
This api should do what it says it should do and should
be very clear
about where it stops, so that I understand what I'm protected from and
what I'm left to do on my own. When it says it protects from something,
there shouldn't be a sneaky way around it. (in lot of ways this is
really where I think canonicalization fits in...)
5. Complete
It should offer tools and design patterns to help me
build a totally
secure web application. Where building generic tools to accomplish the
job doesn't really fit, this api should allow me to enhance or extend it
and in fact encourage me to so that my specific needs are met for
enhancing security. For instance, in the case of data type validation.
Suppose I have an ID parameter that is used to determine what document
we are downloading from a dynamic web application. Some ids are allowed
for some users and others are not... This is really a very common design
pattern for web applications and a poplular spot for security problems.
While its good for us to be able to validate at least that we are
getting a numeric value, it would be really nice to be able to plug in
acceptable values to custom code, a collection in the platforms session
store, a (potentially cached) database query and so forth...
I kind of feel like these things might be a little bit higher level then
they should be, but maybe they will serve as a tool to get the ball
rolling.
-gabe
-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
Owasp-input-api-developers mailing list
Owa...@li...
https://lists.sourceforge.net/lists/listinfo/owasp-input-api-developers
________________________________________________________________________
The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Ernst & Young LLP
|
|
From: Gabriel L. <ga...@bu...> - 2002-06-27 04:35:16
|
Here's some thoughts on high level requirements for the filters project. I hope this can serve somewhat as an example, but also as a diving off place... 1. Support for all major web application development platforms This is really critical to be the security standard for web applications and also to be very complete. But, I think its also pretty important to highlight at a high level so that when we do designs we can do designs that facilitate development for the different platforms. By platforms I'm thinking J2EE/JSP/Servlets, ColdFusion, ASP, PHP, .Net, Perl, ... 2. Simple to use Security is hard to begin with, but forcing developers to jump through hoops isn't realistic given schedule needs, developers experience and knowlege, developer acceptance of the api, and such. Because of this, it really needs to be something that the developer can easily integrate into their application, and has some clear easy to follow steps to put it in in the right places to offer real security. 3. Flexible This one is somewhat in conflict with the one above, but I think we can remedy this in the design process by building mutliple layers that allow interaction in different ways. So, while I may want to just have something that will slide into to the development platform I'm using, I think I'd also like something I can put into a novel application that could be built from scratch or something that can be used with an application that is using http to do new and exiting things. Along the lines of the diff between http proper and http extended to handle WebDAV. 4. Safe This api should do what it says it should do and should be very clear about where it stops, so that I understand what I'm protected from and what I'm left to do on my own. When it says it protects from something, there shouldn't be a sneaky way around it. (in lot of ways this is really where I think canonicalization fits in...) 5. Complete It should offer tools and design patterns to help me build a totally secure web application. Where building generic tools to accomplish the job doesn't really fit, this api should allow me to enhance or extend it and in fact encourage me to so that my specific needs are met for enhancing security. For instance, in the case of data type validation. Suppose I have an ID parameter that is used to determine what document we are downloading from a dynamic web application. Some ids are allowed for some users and others are not... This is really a very common design pattern for web applications and a poplular spot for security problems. While its good for us to be able to validate at least that we are getting a numeric value, it would be really nice to be able to plug in acceptable values to custom code, a collection in the platforms session store, a (potentially cached) database query and so forth... I kind of feel like these things might be a little bit higher level then they should be, but maybe they will serve as a tool to get the ball rolling. -gabe |
|
From: Gabriel L. <ga...@bu...> - 2002-06-27 03:43:08
|
Alex, I think these principles are very good. I totally agree with them. But, I think in some ways we are still stuck in the vision thing. One of the key problems with the vision side of things is that I think we are all close to each other but slightly different so we are having a communication issue where we are just missing each other. I think what I'd like to do is take Mark's suggestion to heart about looking at requirements. In fact, I know this turns the rational model on its head a little, but I'd like to pull together a list of very high level requrements first and foremost and use that to help us drive the vision thing. Why? Primarily because I don't think we have developed a common vocabulary yet, and so we are like trains passing in the night. Here's some examples of what I mean of very high level requirements and I'm going to pick on the topics of the earlier vote and some of the earlier discussions. Canonicalization has been a big part of our discussion and is generally agreed upon as something we need to do. But, in my mind this is really just a solution to solve a requirement that seems to be going unspoken. This requirement is that attackers shouldn't be able to obfuscate an attack so that we cannot block it. The way we are looking at solving this is by normalizing all input so that we can apply a single set of tests to any input... I have no bones to pick with this as the solution, but I'd like to get us to look at the higher level requriements first so that we can get a full coverage idea of what kinds of things we need to think about and our approach to things. I think this should be conducted in a brainstorming fashion, and I think it probably makes sense to do it on this email list. What I will do is be the note taker. I'd like to see people put together emails that run through their high level requirements for what they think this thing needs to do, along with a little bit of explanation so we all can start to get a grip on what each other is talking about and what each others terminology is. Lets not eliminate anything at this point. Once we have all these in place I think we can look at them and try and organize them. My hope is that out of this process we can come up with goals, long term and short term and requirements for different releases of the software. But, that these basic requirements are the building blocks of these larger concepts. -gabe On Wed, 2002-06-26 at 19:06, Mark Curphey wrote: > Alex > > You're a man after my own heart ;-) > > Models like Biba and Bell la Padula should have taught us far more than > appears to have been the case ! > > 1. Monolithic kernels - great example > > 2. Agreed. remember you don't have to feed the world from day one. Why > not define requirements and then prioritize them ? lower priorities can > be dealt with in release 2.0 etc > > 3. Agree. I would have thought that something more than good > documentation seems appropriate. I can get you help with that when the > time comes. > > So why not take this approach ? > > (This is based on the RUP - Rational Unified Process). > > 1. Develop a Vision Document > > http://www.rational.com/media/worldwide/singapore/introducing_processes.pdf is one example on the web but you'll find lots. The vision document include features not requirements. It includes short sections on the problem we are trying to solve, objectives, risks, resources etc > > 2. Develop a set of prioritized requirements > > 3. From the requirements develop your use cases and move on. > > Remember iterative development works better than waterfall development > as well. > > I can help with this sort of stuff if you want. > > I can certainly take a first step at a Vision document on Friday. Just > let me know ! |
|
From: Mark C. <ma...@cu...> - 2002-06-27 02:21:34
|
Alex You're a man after my own heart ;-) Models like Biba and Bell la Padula should have taught us far more than appears to have been the case ! 1. Monolithic kernels - great example 2. Agreed. remember you don't have to feed the world from day one. Why not define requirements and then prioritize them ? lower priorities can be dealt with in release 2.0 etc 3. Agree. I would have thought that something more than good documentation seems appropriate. I can get you help with that when the time comes. So why not take this approach ? (This is based on the RUP - Rational Unified Process). 1. Develop a Vision Document http://www.rational.com/media/worldwide/singapore/introducing_processes.pdf is one example on the web but you'll find lots. The vision document include features not requirements. It includes short sections on the problem we are trying to solve, objectives, risks, resources etc 2. Develop a set of prioritized requirements 3. From the requirements develop your use cases and move on. Remember iterative development works better than waterfall development as well. I can help with this sort of stuff if you want. I can certainly take a first step at a Vision document on Friday. Just let me know ! On Wed, 2002-06-26 at 17:00, Alex Russell wrote: > Hey everyone, > > I can't help but think that we keep falling off track in our focus on > this project. We haven't even completed discussion about the threat > model or security targets yet but we keep getting drawn into discussions > about design. To help clarify a bit, I submit the following general > principles for your review. > > Often I feel that we are treating the project as just another software > development project. Security critical software development MUST be > different from "normal" software development in a couple of ways (I'll > explain the reasons as I go). > > > > > 1.) Simple wins. > > In "traditional" software development, features win. The product that > implements the most features will seem to be the most attractive and > therefore will sell/distribute the most copies. Combined with first > mover and network advantages, the features==market share equation has > been slowly ingrained into the minds of software developers the world > over. In the security world, this axiom breaks completely. > > The enemy of security is complexity (in all of its forms). That which > is harder to do is that much harder to do correctly, and when it comes > to security, we have seen spectacular failures over and over again > because this principle has been broken. The most successful security > products (OpenBSD, MULTICS, etc.) all have one thing in common: they > do things in simple, obvious ways that my be neither either fast nor > elegant, but they work... and work... and work... > > The trend towards kernilization of security features is a direct result > of this maxim, because it can allow developers to significantly decrease > the size of the Trusted Computing Base (TCB), which can then be verified > much more thoroughly. Systems such as tmach, NT, etc, all make use of > this principle in the design of their security-critical subsystems. The > larger the TCB (more code running with privileges), the higher the > probability that attacks will be successful (as witnessed by IIS). Those > familiar with the principle of least privledge may appreciate the > simplicity axiom as a restatement or a generalization of that principle. > > This axiom suggests that it may be desirable to consider "simple and > verified" superior to "elegant and flexible" in the design of our > toolkit. > > > > 2.) Defend against what is likely, not what is possible. > > This runs counter to the normal software development practice of > feature-focused development. When it comes to security, priorities > must be set in what threats will be considered and dealt with as > security be determined by the "does it compile and run?" test. > > If a defender spends 50% of his time defending a threat that has an > incidence coefficient of 0.0002 but a damage (monetary loss, whatever) > of 50,0000 but only spends 10% of his time defending against a problem > with an incidence of 5 but with a damage of "only" 5, is he doing the > right thing? > > Clearly not. > > While the threat with incidence of 0.0002 may be technically > interesting, it is clearly not the source of most loss, and so should be > given appropriate priority when crafting a defense. > > This rule suggests that when drafting a threat model and security > target, it is highly desirable to consult data about the attacks > (frequency, success rates, mitigation factors) carried out against > systems currently in production in the same or similar veins. > > > > 3.) The human factor cannot be ignored. > > Software developers are notorious for just throwing things on > interfaces, betraying a lack of understanding (or interest) in how end > users will wind up using the interfaces they produce. Security design > challenges this assumption by recognizing that humans are the weakest > link in most security sensitive systems. > > Like it or not, humans are involved in almost every security-critical > system. An allegory to point #1, the fact that human are involved > suggests that human error can be a significant risk factor and so should > be dealt with in the use and operation of security critical systems. In > the case of our project, this may suggest that it is highly desireable > to distribute some form of education/training/awareness material with > the toolkit. > > > > 4.) Environments Change > > Assumptions made about environmental factors must be either overt (the > system cannot function with out it) or constantly checked > (assumption==valid or die), as a change in one of these assumptions in > all likelihood _will_ undermine the security engineered into an > application or product. Take, for instance, the case of ATM machines. At > one point, cryptography for ATMs was handled by an "exchange" box that > was external to the ATM itself. This machine handled the communication > between the bank and external networks. The assumption here was that > such machines would be physically close to an ATM because ATMs were > simply too expensive to place outdoors or have more than one at any > branch. > > When the price of ATMs fell dramatically, they started to be placed in > many locations not accounted for by this assumption. Yet in some > systems, encryption was still carried out in the central exchange > machine located in the bank branch, meaning that ATMs not near the bank > were transmitting information in the clear for possibly miles. > Environmental assumptions that were not explicitly designed in such a > way as to break the system when they changed. As a result, very insecure > systems were built on top of what was once a demonstrably secure > infrastructure. > > > > > I believe that unless we (as a team) use these axioms in judging the > quality of a design/implementation for our project, we may wind up > creating a really whiz-bang toolkit that doesn't do very much to ease > the burden of developers in creating secure web applications. > > So what does everyone else think? Can we develop with these principles? > > -- > Alex Russell > al...@Se... > al...@ne... |
|
From: Alex R. <al...@se...> - 2002-06-27 00:00:28
|
Hey everyone, I can't help but think that we keep falling off track in our focus on this project. We haven't even completed discussion about the threat model or security targets yet but we keep getting drawn into discussions about design. To help clarify a bit, I submit the following general principles for your review. Often I feel that we are treating the project as just another software development project. Security critical software development MUST be different from "normal" software development in a couple of ways (I'll explain the reasons as I go). 1.) Simple wins. In "traditional" software development, features win. The product that implements the most features will seem to be the most attractive and therefore will sell/distribute the most copies. Combined with first mover and network advantages, the features==market share equation has been slowly ingrained into the minds of software developers the world over. In the security world, this axiom breaks completely. The enemy of security is complexity (in all of its forms). That which is harder to do is that much harder to do correctly, and when it comes to security, we have seen spectacular failures over and over again because this principle has been broken. The most successful security products (OpenBSD, MULTICS, etc.) all have one thing in common: they do things in simple, obvious ways that my be neither either fast nor elegant, but they work... and work... and work... The trend towards kernilization of security features is a direct result of this maxim, because it can allow developers to significantly decrease the size of the Trusted Computing Base (TCB), which can then be verified much more thoroughly. Systems such as tmach, NT, etc, all make use of this principle in the design of their security-critical subsystems. The larger the TCB (more code running with privileges), the higher the probability that attacks will be successful (as witnessed by IIS). Those familiar with the principle of least privledge may appreciate the simplicity axiom as a restatement or a generalization of that principle. This axiom suggests that it may be desirable to consider "simple and verified" superior to "elegant and flexible" in the design of our toolkit. 2.) Defend against what is likely, not what is possible. This runs counter to the normal software development practice of feature-focused development. When it comes to security, priorities must be set in what threats will be considered and dealt with as security be determined by the "does it compile and run?" test. If a defender spends 50% of his time defending a threat that has an incidence coefficient of 0.0002 but a damage (monetary loss, whatever) of 50,0000 but only spends 10% of his time defending against a problem with an incidence of 5 but with a damage of "only" 5, is he doing the right thing? Clearly not. While the threat with incidence of 0.0002 may be technically interesting, it is clearly not the source of most loss, and so should be given appropriate priority when crafting a defense. This rule suggests that when drafting a threat model and security target, it is highly desirable to consult data about the attacks (frequency, success rates, mitigation factors) carried out against systems currently in production in the same or similar veins. 3.) The human factor cannot be ignored. Software developers are notorious for just throwing things on interfaces, betraying a lack of understanding (or interest) in how end users will wind up using the interfaces they produce. Security design challenges this assumption by recognizing that humans are the weakest link in most security sensitive systems. Like it or not, humans are involved in almost every security-critical system. An allegory to point #1, the fact that human are involved suggests that human error can be a significant risk factor and so should be dealt with in the use and operation of security critical systems. In the case of our project, this may suggest that it is highly desireable to distribute some form of education/training/awareness material with the toolkit. 4.) Environments Change Assumptions made about environmental factors must be either overt (the system cannot function with out it) or constantly checked (assumption==valid or die), as a change in one of these assumptions in all likelihood _will_ undermine the security engineered into an application or product. Take, for instance, the case of ATM machines. At one point, cryptography for ATMs was handled by an "exchange" box that was external to the ATM itself. This machine handled the communication between the bank and external networks. The assumption here was that such machines would be physically close to an ATM because ATMs were simply too expensive to place outdoors or have more than one at any branch. When the price of ATMs fell dramatically, they started to be placed in many locations not accounted for by this assumption. Yet in some systems, encryption was still carried out in the central exchange machine located in the bank branch, meaning that ATMs not near the bank were transmitting information in the clear for possibly miles. Environmental assumptions that were not explicitly designed in such a way as to break the system when they changed. As a result, very insecure systems were built on top of what was once a demonstrably secure infrastructure. I believe that unless we (as a team) use these axioms in judging the quality of a design/implementation for our project, we may wind up creating a really whiz-bang toolkit that doesn't do very much to ease the burden of developers in creating secure web applications. So what does everyone else think? Can we develop with these principles? -- Alex Russell al...@Se... al...@ne... |
|
From: Nik C. <ni...@ni...> - 2002-06-26 16:48:30
|
On Wed, 26 Jun 2002, vertigo wrote: > 1) Data-type Validation (for or against) For. > 2) Range checking (for or against) For. > 3) Signature Scanning (for or against) Against for version 1, should be version 1.1 issue. Also, I am a strong believer of 'deny all by default' irf.efnet.org - #owasp now if you are interested. -Nik |
|
From: Alex R. <al...@se...> - 2002-06-26 16:44:20
|
vertigo wrote: > As we have not been able to come to a consensus about some > major design decisions, I propose we vote on the following > issues: > > 1) Data-type Validation (for or against) Against as mandatory, for as conditional. > 2) Range checking (for or against) Against as mandatory, for as conditional. > 3) Signature Scanning (for or against) I'm not sure this is the right question to be asking. We haven't even decided on goals yet. Am I right? Somehow all of these seem to be design constraints and not project goals. Or am I off track? -- Alex Russell al...@Se... al...@ne... |
|
From: vertigo <ve...@pa...> - 2002-06-26 16:38:08
|
As we have not been able to come to a consensus about some major design decisions, I propose we vote on the following issues: 1) Data-type Validation (for or against) 2) Range checking (for or against) 3) Signature Scanning (for or against) If anyone has other items that think should go to a vote, feel free to append this list. Gabe, as the official project manager I would appreciate it if you could organize a proper vote once we have settled on items. Arguments for and against each issue should precede the vote. Nathan |
|
From: Steve S. <sj...@Ju...> - 2002-06-23 15:47:11
|
At 03:28 PM 6/21/2002 -0700, you wrote: >You know I am far from an expert on this in any shape or form, but if I >were doing this (and this may already be assumed in another mail >thread) before solving that problem I would first define a system that >allows the developer to specify a small set of valid input chars and >reject everything else at the boundary. Its pretty damn hard to run sql >injection, xss etc anywhere if you only allow A-Z ASCII as input. A-Z a-z 0-9 - (dash) _ (underscore) space (ASCII 32) I *think* we're safe with those characters... -- Steve Sobol, CTO (Server Guru, Network Janitor and Head Geek) JustThe.net LLC, Mentor On The Lake, OH 888.480.4NET http://JustThe.net "In a 32-bit world, you're a 2-bit user/You've got your own newsgroup: alt.total.loser" - "Weird Al" Yankovic, "It's All About the Pentiums" |
|
From: Mark C. <ma...@cu...> - 2002-06-21 22:42:40
|
Interesting debate. My 2 cents worth for what they are worth. You know I am far from an expert on this in any shape or form, but if I were doing this (and this may already be assumed in another mail thread) before solving that problem I would first define a system that allows the developer to specify a small set of valid input chars and reject everything else at the boundary. Its pretty damn hard to run sql injection, xss etc anywhere if you only allow A-Z ASCII as input. This would cover the huge majority of simple apps that allow users to enter text, be simple to implement and effective. Most canonicalization is dependent on the web server anyways and you may not have that much control over the input. Canonicalize a URL encoded or Unicodes version of anything and it wont be A-Z anymore so would drop. Of course it needs to be put into a safe data type, operated on etc before it becomes a variable in play so to speak. Then comes the more difficult problems you discuss. I like the idea of defining an inbound and outbound gateway and (boundary) and operating in that. I would agree that all data should be checked, but to an extent as you point out thats a huge task and maybe beyond this project. It may also mean that implementing what you design would require a significant amount of reworking for existing applications. The AV paradigm would seem to work well. You check file reads and writes, not every thread call. Maybe in Java it becomes a callable service that your markup and input can call when receiving and writing data. I think that approach certainly scopes the project much better, makes deployment and post-production customization easier etc. > -------- Original Message -------- > Subject: [Owasp-input-api-developers] turning the problem inside out > Date: Tue, 18 Jun 2002 20:12:13 -0500 > From: Alex Russell <al...@se...> > Organization: SecurePipe > To: owa...@li... > > Ok, so I had a thought this evening. Perhaps we're looking at things in > a way that's not helping us figure out what works best from an applied > standpoint. > > My thought is that perhaps we should think a bit more about how we might > filter at _every_ input/output in a system. Seems to me like I have been > trying to solve the problem of accounting (or filtering) for every > possible abuse scenario as soon as I get the data, and the more I think > about it the more I realize that this eventually works against us. I > forces me (and end developers) to think about every use of their data > further down the road than is necessaray, breaking the "don't make me > think" principle. > > So perhaps we can do better by only addressing the immediate threats. > Let me expand on that before you flame me into oblivion. Consider the > following scenarios: > > 1.) taking form input > 2.) insert a string into my database > 3.) pulling a peice of data out of a database > 4.) displaying data to a client > > Were I to consider these data flows through the system as a whole (as > they could easily be the same piece of data), then I've got some thorny > questions, and it's my instinct to handle them all up front (which is > what I've been tempted to design for thus far). But what happens when I > get data from another input (say a file) and I don't KNOW where it's > going to end up (as I often may not at various stages in a project)? > Well, I have to filter for everything and hope I don't loose what I > need. Strongly sub-optimal. I (at least) have been considering how I'm > going to protect the entire system from from between items 1 and 2, > kinda like: > > (1) -> filter(for everything) -> (2) -> (3) -> (4) > > at which point I'm just left praying that I've thought of everything at > 1. I also realized this evening that if we design a system that is > _capable_ of this (easily), that's exactly how it's going to be used. > > What might work better from a strictly security-related perspective > would be to consider boundaries as the important parts of the system, > and not necessarialy think beyond them. So, for instance, consider > getting intput from a form. My intput is from the server, my output is > to the runtime. If I concern myself only with the threats exposed at > this boundary, my job gets a lot more managable. I only have to filter > at this boundary for things that adversely affect me in the runtime. > > Now consider (2). If I do boundary-centric filtering, I concern myself > with the input from the runtime environment (which I can call a "dirty" > input from the persepctive of the DB) and only worry about the class of > things that can go wrong with the boundary I'm crossing: SQL injection, > SQL type mismatches, etc. I've strictly defined what the types are on > either side (because one side enforces them) and so I don't have ot > worry about cross-language problems: I'm talking SQL, it has > requirements that my filter at this boundary MUST be conscious of. We > filter the malicious inputs to my subsystem here and move on. > > But you say "what about XSS?!?, you're ignoring it!!". Yes, I am. But > not for long. Consider the SELECT from the DB into a variable in my > runtime: if I consider the input from the SQL "dirty", I can strongly > filter all my inputs to the environment and not have to worry about > "where" the data came from (which is really "what boundary did it pass > from to get into the DB?"). All I have to worry about are my current > boundaries. > > Likewise when I output from the runtime to an external listener > (whatever it may be). I have NO CLUE how my data is going to really be > used between (1) and (2), but at the outbound from the environment to > the end client, I know a LOT more about who I have to protect and how. > > So here's what I'm proposing: we define "boundary" filters, not > necessarialy filters for one type of attack or another. We could > implement these using a common signature backend or whatever (although I > think that's way too much overhead, personally). By implementing the > toolkit this way, we will "force" developers to think of their data as > "tainted" as it crosses each boundary (which is a sane assumption, > actually), while at the same time breaking up the load of filtering and > the mental load of tracing data through the system explicitly. > > As an added benefit, large projects that may be developed by many > developers often NEVER know where data REALLY comes from or goes to, or > for that matter what touches it in between. By breaking up our task into > boundary based segments, we can enable large projects like this to > become hardened in a sysetmic way that doesn't require the kinds of > complex context that can easily become mishmashed in the minds of > developers. > > Possible downsides: filtering at the boundary is drop dead simple in > terms of what an implementer has to know how to use at each step, but it > does mean that security has to be "added" at each step. This creates > more raw locations in code where the API has to be applied, and that > might be a significant detractor. A "scanner" that looks for I/O calls > might be one way to address this issue. Grouping of boundary checkers > (providing combinations of the most common boundaries?) might also be a > way to decrease this problem, but overall I feel that once a developer > is "used to" applying filters everywhere, this might become less of a > concern. > > The more I consider the sheer number of permeutations that we would have > to provide for when doing "monolithic" filtering, the less approachable > the problem seems. By breaking it up into situations where we filter at > every boundary crossing, we can provide much simpler syntax that > directly addresses the problems presented at each "place" in the system. > > Thoughts? > > -- > Alex Russell > al...@Se... > al...@ne... |
|
From: Mark C. <ma...@cu...> - 2002-06-21 20:16:45
|
You know I seem to own the mailing list but don't have the password. So I cant even add myself to it as it requires auth of the admin subscribing ;-) Hence all I saw was the same old please approve or deny ma...@cu... each night :-) God I am such a looozer sometimes. Its being reset anyways. As for the main OWASP page we were hoping to get a high level page thats consistent with each project. No need to do detail design plans. The WebScarab one is a template. Just means we all have the same look and feel for now until we do the portal when we can get more granularity. What we found helpful with WebScrarab was the workbook. The sections included requirements etc so it kinda lead us to creating all the doc needed. I guess the owasp.org page should be like the RUP vision statement. Zed Shaw has also been playing with Wiki for this as editing it all is much easier. Not sure if we can install CGI's at Sourceforge but if we could that would be a great solution. A sample dev Wiki is at http://projects.itservices.ubc.ca/cgi-bin/moin.cgi I have often found in the past that by plodding through a vision statement, non functional requirements and some use cases helps solidify everyones idea on the design. If there are any touchy subjects simple voting can work well. I am going to read Alex's project goal proposal now. On Fri, 2002-06-21 at 11:47, Gabriel Lawrence wrote: > Howdy folks, > > So, project manager hat on... > > What we've done this week: > > 1. Reviewed old info and cvs code (individually) > 2. IRC chat > 3. Posted transcript of IRC chat > 4. Alex put togheter a summary and project goal proposal > 5. Some discussion on project goal summary > > What we really need to do next is come to a consesnsus on the project > goals and pull that together in to a document. It feels a little to me > that we haven't really reached a consensus yet, rather that different > viewpoints have been put forth. Correct me if I am wrong. How can we > move forward to make sure that there is common ground and common > agreement on what this project will be doing? > > On top of this, Mark is hoping to get our page updated, and was asking > for it to be done this weekend. I'm a little uncomfortable spending too > much time changing things on the site until I feel like we all have a > common view of what we are doing. So, what are the next steps? > > -gabe > |
|
From: Alex R. <al...@se...> - 2002-06-21 19:26:39
|
Gabriel Lawrence wrote: > What we really need to do next is come to a consesnsus on the project > goals and pull that together in to a document. It feels a little to me > that we haven't really reached a consensus yet, rather that different > viewpoints have been put forth. Correct me if I am wrong. I think we can summarize what we've agreed on thus far as: 1.) we dissagree on a lot of stuff 2.) we must canonicalize data before filtering 3.) we're supposed to filter stuff...and stuff... 4.) that I can't spell. and what we dissagree on as: 1.) how far the project should go in protecting developers 2.) whether or not our target developers know a compiler from a hole in the ground 3.) whether or not type checking is sane, considering we're not all programming in nice, tidy, languages like Java 4.) how "signatures" should be stored 5.) whether or not we should use "signatures" at all 6.) how many licks it takes to get to the center of a tootsie-pop 7.) how much work should be required on the part of developers to create/invoke a given filter. > How can we move forward to make sure that there is common ground and common > agreement on what this project will be doing? I submit that we need to set out a list of points that we need to agree on. Once those points are decided, they should more or less dictate the overall design, and we can then start to iterate on a reference implementation. -- Alex Russell al...@Se... al...@ne... |
|
From: Matt W. <wi...@ce...> - 2002-06-21 19:01:57
|
On Friday 21 June 2002 13:47, Gabriel Lawrence wrote: > Howdy folks, > > So, project manager hat on... > > What we've done this week: > > 1. Reviewed old info and cvs code (individually) > 2. IRC chat > 3. Posted transcript of IRC chat > 4. Alex put togheter a summary and project goal proposal > 5. Some discussion on project goal summary > > What we really need to do next is come to a consesnsus on the project > goals and pull that together in to a document. It feels a little to me > that we haven't really reached a consensus yet, rather that different > viewpoints have been put forth. Correct me if I am wrong. How can we > move forward to make sure that there is common ground and common > agreement on what this project will be doing? > > On top of this, Mark is hoping to get our page updated, and was asking > for it to be done this weekend. I'm a little uncomfortable spending too > much time changing things on the site until I feel like we all have a > common view of what we are doing. So, what are the next steps? > I think the problem is that some of us (myself included) have been doing = that project "no-no" of trying to force design-related ideas before we even ha= ve our project requirements set. We still need to know what, before we worry about how. I believe there were a few things we know we need to do,=20 such as: =091) Canonicalize data =092) Input/output filtering Other things are still not agreed upon such as: =093) Type checking =094) Range checking This is, of course, an over simplified list, and by all means, please add= to it. But we need to decide on whats what before we continue.. -matt --=20 Matthew Wirges Developer, CERIAS Incident Response Database wi...@ce... -- [765]49-67707 |
|
From: Gabriel L. <ga...@bu...> - 2002-06-21 18:49:09
|
Howdy folks, So, project manager hat on... What we've done this week: 1. Reviewed old info and cvs code (individually) 2. IRC chat 3. Posted transcript of IRC chat 4. Alex put togheter a summary and project goal proposal 5. Some discussion on project goal summary What we really need to do next is come to a consesnsus on the project goals and pull that together in to a document. It feels a little to me that we haven't really reached a consensus yet, rather that different viewpoints have been put forth. Correct me if I am wrong. How can we move forward to make sure that there is common ground and common agreement on what this project will be doing? On top of this, Mark is hoping to get our page updated, and was asking for it to be done this weekend. I'm a little uncomfortable spending too much time changing things on the site until I feel like we all have a common view of what we are doing. So, what are the next steps? -gabe |
|
From: vertigo <ve...@pa...> - 2002-06-20 02:20:19
|
On Tue, 18 Jun 2002, Matt Wirges wrote: > On Tuesday 18 June 2002 15:51, vertigo wrote: > > I am uncertain of the experience with and opinions toward OO > > that the group may have. > > There's nothing really wrong with OO. I believe the bulk of our target languages > support it (perl,python,asp,C++, Java, PHP, ruby) albeit Perl's OOP is dirty -- its pretty > much "stapled on", but it does work (though, if Perl6 ever becomes non-vaporware, this'll change). > > > The word "function" seemed to pervade > > the conversation, as in "wrap _EVERYTHING_ with one of our fun- > > ctions." The design I had in mind involved adding unfiltered > > parameters to a filter object, calling the filter() method, then > > retrieving filtered parameters from it, as in the following > > lines of code: > > Here's where I begin to disagree. The bulk of your web app developers (commercial or personal) > are not going to want tons of object instantiations and umpteen method invocations just to get one lousy > stinking "cleaned" piece of data. > True, and this is where we have to make some serious decisions. It's a fairly standard trade-off: performance for maintainability and extensibility. Write everything in assembly if you want speed (FDNY uses VAX assembly); I prefer to be able to read and maintain the code. Your standard webapp developers will not see the internals of the API--only the public interface (which may be fairly slim). Without reading the source, there's no way to tell how many methods are being called. Just because function calls have overhead doesn't mean we should abandon their use. On the other hand, if the API is slow, people may not want to use it in existing apps that are already slow. I think this problem goes directly to the heart of secure systems. Security adds overhead, whether it is SSL or Snort. Is the overhead acceptable? Is the additional time taken to filter input less of a problem than a successful attack? Ooops, forgot about something. Will continue later Nathan |
|
From: Steven J. S. <sj...@Ju...> - 2002-06-20 02:10:39
|
On Wed, 19 Jun 2002, vertigo wrote: > > > This long lifecycle, approach, however, does not make sense in Perl, > > > unless one uses Apache and mod_perl. While Java can afford fairly > > > expensive instantiation, a Perl CGI cannot. Instantiation may be > > > handled differently, if at all. It may not even be OO. > > > > Why not? > > No reason at all (to do OO Perl). I'm just worried about Perl having > to parse a potentially large signature file every time a request is made. > I've never had the misfortune of working with a Perl CGI that was actually > slower than a servlet (at Phlair, the bottlenecks were always the > Java), so I'm not terribly concerned--but it's just one of those things I > worry about. If you're worried about the amount of resources a process running a Perl CGI might use, perhaps using a module like Fastcgi would address those issues. -- Steve Sobol, CTO JustThe.net LLC, Mentor On The Lake, OH 888.480.4NET - I do my best work with one of my cockatiels sitting on each shoulder - 6/4/02:A USA TODAY poll found that 80% of Catholics advocated a zero-tolerance stance towards abusive priests. The fact that 20% didn't, scares me... |
|
From: vertigo <ve...@pa...> - 2002-06-20 01:45:27
|
On Wed, 19 Jun 2002, Steven J. Sobol wrote: > > This long lifecycle, approach, however, does not make sense in Perl, > > unless one uses Apache and mod_perl. While Java can afford fairly > > expensive instantiation, a Perl CGI cannot. Instantiation may be > > handled differently, if at all. It may not even be OO. > > Why not? No reason at all (to do OO Perl). I'm just worried about Perl having to parse a potentially large signature file every time a request is made. I've never had the misfortune of working with a Perl CGI that was actually slower than a servlet (at Phlair, the bottlenecks were always the Java), so I'm not terribly concerned--but it's just one of those things I worry about. Nathan |
|
From: Steven J. S. <sj...@Ju...> - 2002-06-19 16:48:17
|
On Wed, 19 Jun 2002, vertigo wrote: > Making this transparent to the average webdev is a little too much to ask. > Also, making it "generic" is a little too much to ask for when considering > the broad range of implementation languages available. That was going to be the next point I made. > Making something > "generic" is often times equivalent to simplification. I think rather > than concentrating on how to make this generic as possible, we make some > decisions regarding the following: > > 1) Core features > 2) Public Interface > 3) Configuration > 4) Signature Definition, Storage, and Loading > 5) Rule/Policy Definition, Storage, and Loading > 5) Reporting Framework > 6) Compatibility (between implementations) Within 4 and 5 I'd think we need to subclassify for the different types of exploits - SQL injection, XSS, etc. > The Java version, for example, will be running in its own thread, and > could possibly by accessed by several servlets many times throughout > the lifecycle of the application server in which it is running. Same with the PHP module, if we do this project as a PHP extension. > This long lifecycle, approach, however, does not make sense in Perl, > unless one uses Apache and mod_perl. While Java can afford fairly > expensive instantiation, a Perl CGI cannot. Instantiation may be > handled differently, if at all. It may not even be OO. Why not? -- Steve Sobol, CTO JustThe.net LLC, Mentor On The Lake, OH 888.480.4NET - I do my best work with one of my cockatiels sitting on each shoulder - 6/4/02:A USA TODAY poll found that 80% of Catholics advocated a zero-tolerance stance towards abusive priests. The fact that 20% didn't, scares me... |
|
From: vertigo <ve...@pa...> - 2002-06-19 16:30:06
|
Making this transparent to the average webdev is a little too much to ask. Also, making it "generic" is a little too much to ask for when considering the broad range of implementation languages available. Making something "generic" is often times equivalent to simplification. I think rather than concentrating on how to make this generic as possible, we make some decisions regarding the following: 1) Core features 2) Public Interface 3) Configuration 4) Signature Definition, Storage, and Loading 5) Rule/Policy Definition, Storage, and Loading 5) Reporting Framework 6) Compatibility (between implementations) The Java version, for example, will be running in its own thread, and could possibly by accessed by several servlets many times throughout the lifecycle of the application server in which it is running. As are the servlets, it is conceivable that the filter could be loaded once--minimizing complex object construction, and have a fairly long lifecycle. This is due to the nature of the Java language and virtual machine. This long lifecycle, approach, however, does not make sense in Perl, unless one uses Apache and mod_perl. While Java can afford fairly expensive instantiation, a Perl CGI cannot. Instantiation may be handled differently, if at all. It may not even be OO. I think we should remember that there are fundamental architectural differences between implementation languages that cannot be generalized away into the aether. And rather than trying to fit square pegs into round holes, we should create prism-shaped containers for each peg and push these through triangular holes. (I kind of lost the metaphor at the end there, sorry.) Nathan Nathan On Tue, 18 Jun 2002, Steven J. Sobol wrote: > On 18 Jun 2002, Gabriel Lawrence wrote: > > > So, I see the first step of this process being developing some simple > > api's that allow developers to start incorporating this stuff into their > > applications. I think at this level it would be key to make this stuff > > as generic as possible as the code will need to be ported to multiple > > environments: Python, Java, PHP, Perl, C/C++, ColdFusion and so on... > > (Apologies for not making it to irc yesterday) > > I don't know how "generic" we'll be able to make the code... > > > And finally, we need to incorporate technology specific solutions into > > the api so that we can become a layer of protection wrapped around the > > technology supporting it where those technologies are weak or create > > holes. > > Is our goal to make this stuff transparent to John Q. Webappdeveloper? > > > -- > Steve Sobol, CTO JustThe.net LLC, Mentor On The Lake, OH 888.480.4NET > - I do my best work with one of my cockatiels sitting on each shoulder - > 6/4/02:A USA TODAY poll found that 80% of Catholics advocated a zero-tolerance > stance towards abusive priests. The fact that 20% didn't, scares me... > > > > ---------------------------------------------------------------------------- > Bringing you mounds of caffeinated joy > >>> http://thinkgeek.com/sf <<< > > _______________________________________________ > Owasp-input-api-developers mailing list > Owa...@li... > https://lists.sourceforge.net/lists/listinfo/owasp-input-api-developers > |
1 message has been excluded from this view by a project administrator.
