[Esapi-dev] Changing ESAPI.properties

[Kevin W. Wall]

On 11/01/2010 04:01 AM, Mostafa Siraj wrote:
> Hello,
> 
> Well I would go with what Chris and Jim finally went to but still we know
> that this is a staging step -it can't be like that forever- so we should
> also plan how can we make this better -so that it can be secure and not
> confusing-.

To this end, I've created Google Code issue # 166 on this.
<http://code.google.com/p/owasp-esapi-java/issues/detail?id=166>

> @Jeff about loading multiple properties files in which devs can override
> certain properties by writing another ESAPI.properties files, I totally
> don't agree with this, I used to see this type of deployments in .NET
> applications (machine.config and dozens of web.config along with the
> source hierarchy) and as Chris noted before most of the development teams
> are not mature yet, so there will be no planning or locking for certain
> sensitive properties (as you hope). I had to built my own tool that searches
> for all the config files and looks for insecure config, the tool was
> successful but it took me a lot of time to do it right. we have a key
> advantage of centralizing the config files, it's much easier to review and
> audit. (the advantages we took by the other approach -multiple config- is
> less valuable than its disadvantages)

If that is what happens, I would say that you were dealing with a *very*
immature process and/or operations team.  The operations team should
definitely own the machine.config. Dev teams may or may not deploy
web.config files as needed. But their should be a way for the operations
team to lock down what can be changed. Otherwise, you have loose cowboy
programmers shooting up the range.

If it takes tools to manage that, so be it. If need be, we can provide
such scripts and/or monitoring mechanisms for ESAPI. (For example, throwing
a SecurityException or some sort of Error if a developer tries to override
a property that is supposed to be locked down by the operations team will
definitely get the attention of everyone. IMO, if your management won't
back such "drastic" action, then you are already fighting a loosing battle.


>>  That's absolutely correct for a mature development team - how many mature
>> development teams are there really writing web applications in the grand
>> scheme of things. I agree completely with you on principle, don't get me
>> wrong - security through obscurity by itself is ridiculous, however, in an
>> ideal world I think a certain amount of misdirection and obscurity should be
>> among the many layers in a security program.

I agree. STO can't be the *only* hurdle, but it can be one of many and can
serve to at least slow an attacker down, hopefully enough to where their
actions will be detected.

>>  Does having just an extra layer of obscurity really fix anything, no?does
>> it hurt anything? I definately don't think so.

_Probably not_, but it could if the obfuscation is so complex that it otherwise
introduces a vulnerability in and of itself.

>> <snip>
>>  Deal?

Deal. Will deal with this soon. (Once I fix Maven. Looking for an updated RPM
in a yum channel I already support.)

>> On Mon, Nov 1, 2010 at 2:11 AM, Jim Manico <jim.manico at owasp.org> wrote:
>>
>> If you contractors have access to your production properties file, then you
>> are doing change management and deployment process VERY wrong. Developers
>> should never have access to production passwords and master keys.
>>
>>  I still don't buy this argument. Clarity is more important than security
>> by obscurity in this case, in my (lonely) opinion.
>>
>>  I worked at Sun for 6+ years working on Java web applications for the
>> executive teams - and never once was exposed to a production password.
>> That's the way to roll.

While I agree with you, in my 30+ years, I've only seen this done in about
25-30% of the cases. It especially gets neglected when the operation team is
a company that you contract out to. At that point, they (the operations teams)
no longer want to be responsible for these things because of potential liability
issues should something like a DB password be cracked because a weak password
be created by them. So instead, they require the dev teams to set such
passwords.

That's one reason when I have my team provide software, I generally try to
require them to provide a tool to set things like that which the operations
teams execute at the time they deploy the production software. If all choices
are removed from them, that absolves them of any liability issues. Of course
the downside is that its one more thing for the dev teams to produce.  On a
related note, I probably will provide something like this for creating
SecretKeys of some specific type and provide that under src/examples, as its
too important to leave to chance or naive developers. That will at least serve
until we can get a real key management system integrated into ESAPI.

-kevin
--
Kevin W. Wall
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME