Re: [SC-L] SC-L Digest, Vol 6, Issue 56
At 7:56 PM +0200 3/19/10, AK wrote: > It is way easier for attackers to reverse engineer desktop applications > than web applications. Assuming proper server configuration, it is next > to impossible for an attacker to get the server side source code or > compressed form (e.g WARs) for a web application and proceed with > disassembly/decompilation/patching. Assuming proper _desktop_ configuration, the user does not have the ability to modify the programs they will execute, nor change the protections of objects on the system. http://nvd.nist.gov/fdcc/fdcc_faq.cfm Yes, physical access to a computer means ultimately it is possible to gain control, but the necessary measures to not constitute "easier", and given control of one test machine it is not at all trivial to transfer that to control of another machine, especially if the machines are not connected to a common network. -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] SC-L Digest, Vol 6, Issue 56
> > As soon as a "non-developer" creates code, they are no longer a > "non-developer". By definition, they are now a developer! > > Of course, they may completely lack any kind of knowledge about security. > Just like most developers, I should add. I expect this problem to *increase* > over time. > > > For the case that one is creating a product/service I will have to rephrase a bit. Substitute "non-developer" with "person who lacks all but the most basic notions of software engineering". So, technically, yeah they are developers but probably they are not good developers and will run to a multitude of problems, one of which will be security. However, by non-developers, I was meaning people who write code as a "one-off", (e.g. a security consultant writes some quick and dirty code to fuzz something, or someone writing a script for home use). Even if the security knowledge is there, since security is not a required property, it just will not in the resultant code, as the code is supposed to be used a few times and then thrown away (or hopefully rewritten :-) ) > That may be true in some places. But all too often real knowledge and > expertise is rare. Many "System Admins", esp. in the Windows world, do not > understand the underlying technology at all. They only know how to how to > point-and-click based on recipes created by others (e.g., local instructions > or whatever Google tells them). All too often we *train* while ignoring > *education*. > > When they have to program at all, these kinds of people perform "cargo cult > programming" (see http://en.wikipedia.org/wiki/Cargo_cult_programming ). > If an organization hires (or outsources to) point-n-click admins (which, I'll hazard a guess, on average will cost cheaper than the admins who have invested time sharpening their saw), the organization will most likely have operational problems, which are not limited to security, even before the admins type "shebang", IMHO. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] SC-L Digest, Vol 6, Issue 56
It is way easier for attackers to reverse engineer desktop applications than web applications. Assuming proper server configuration, it is next to impossible for an attacker to get the server side source code or compressed form (e.g WARs) for a web application and proceed with disassembly/decompilation/patching. I do not have any experience with obfuscating or otherwise armoring executables created from scripting languages (such as win32's py2exe) but I would venture a guess that it would be tedious and less effective than armoring a C/C++ based executable. To turn the argument the other way round, if we accept what you say as correct within the realm of web applications, the Ruby-On-Rails and Django guys (to name but two) are in a serious folly and are not able to provide secure frameworks owing to their choice of scripting languages. I, for one, do not that this is the case :-) sc-l-requ...@securecoding.org wrote: Message: 6 Date: Thu, 18 Mar 2010 15:11:29 -0400 From: ljknews To: sc-l@securecoding.org Subject: Re: [SC-L] market for training CISSPs how to code (Matt, Parsons) Message-ID: Content-Type: text/plain; charset=us-ascii At 7:36 PM +0200 3/18/10, AK wrote: > > Who says so, in the context of web applications? > > I can see it (somewhat) from a "desktop" application > > perspective, but how is this relevant in web apps? > Why should standards for a "web" application be different than for a "desktop" application ? -- Larry Kilgallen ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___