[OWASP-GUIDE] Frameworks (.NET and J2EE) and Langauage Chapters

[Andrew J. Downum]

Absolutely true that ASP.NET is not the whole .NET framework.  My worry
here is that we need to maintain a focus on the stuff that will be
important to web developers or we risk losing them in a maze of
unrelated technologies.

The aspects of Code Access Security are fascinating, yes, I absolutely
agree with you there, and were we writing about client application
security I would say that the most important factor.  However it has
almost no bearing into the traditional web application.  In almost every
case I have ever seen web applications are being run with local machine
evidence, and therefore with Full Trust.

If we were to cover the ability to embed .NET objects into web pages
then CAS becomes very quickly pertinent in a client-side context.  

Let me know what the rest of you think on this.  I could certainly go a
different direction.

 ~ Andrew 

-----Original Message-----
From: Adrian Wiesmann [mailto:awiesmann at swordlord.org] 
Sent: Tuesday, December 31, 2002 6:00 AM
To: owasp-guide at lists.sourceforge.net
Subject: Re: [OWASP-GUIDE] Frameworks (.NET and J2EE) and Langauage
Chapters

I was away for a few days (and will be again tomorrow) and read the
mails
about .NET just now:

> For .NET I think this means the following:
<snip>
> 1. ASP.NET Authentication methods
<snip>
> 2. ASP.NET Authorization
<snip>
> 3. ADO.NET (Data Access)

I am not quite sure if this is really what one wants to hear about .NET
security. ASP.NET is not the .NET Framework... While one can argue that
ASP.NET is the important part of .NET for web services, the main code
will
run in the .NET framework and every good developer which wants to write
secure code needs to know that framework through and through. And you
may
also want to code your own web service or web enabled cod ein .NET which
surely will not be running ASP.NET...

I would propose the following themes as well. I did a training course
for
developers once, and they did quite interested in those:

- User- vs. Code-Identity based security. (It is quite unusual what
different kinds of security enforcement possibilities are in the .NET
Framework)
- Evidence
- Membership conditions, Code Groups
- Application Domains
- Permissions (Code, Identity, Other)
- Declarative and Imperative Security
- Permission Set's
- Execution Stack
- Managed Code
- Assemblies
- Policies (4 policy levels)
- Validation and Verification of PE Files and Metadata

And then I would add where that .NET framework hooks itself into ASP and
the OS or other technologies.

Regards,
Adrian


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Owasp-guide mailing list
Owasp-guide at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owasp-guide