[Owasp-alabama] How much debug info is too much, and is its exposure a risk?

owasp-alabama at lists.owasp.org owasp-alabama at lists.owasp.org
Tue Jul 5 20:40:09 EDT 2011


That is a good question. I am not sure how to answer it. Given they have
access to the database directly I don't know how much you would protect. If
anything, I would say to code it securely just to ensure that it isn't
mishandled. You mentioned earlier that it potentially could be facing the
open internet. I would code with that scenario in mind and look at it from
the eyes of a person using it on the internet. If it were the case, at that
point there are many errors I would want to try to hide. Outside of that, I
honestly am not sure.

Allen

On Mon, Jul 4, 2011 at 12:40 PM, <owasp-alabama at lists.owasp.org> wrote:

> Since we are selling this for internal use to customers and we cannot
> predict where it will exactly be run, actually we allow virtually any web
> server type.  We need to be able to determine the system state, settings
> etc.
>
> the site is designed with a large amount of automations based on client
> criteria, etc (hard to explain without revealing too much)  We would need to
> know much of this data and how it was processed to determine failure in
> these areas.. this is developer only, but our support guys are trained at
> not only FAQ stuff but system function and design to help them figure out
> issues more clearly.
>
> connections to other systems would need to log those handshaking and
> interactions, these customers (admins) may need to view.
>
> what im looking for is to determine if there are some sorts of info that
> should never be revealed?
>
>
> I guess the REAL question here is, in the perspective of a customer
> installed APP, (not a web service product) do we need to heavily restrict
> access to logs, when they have access to the code and SQL DB anyway?
>
> does that help?
>
> Chris.
>
> On Jul 4, 2011, at 12:09 PM, owasp-alabama at lists.owasp.org wrote:
>
> Chris,
>
> Can you provide a couple of scenarios for what the information would be
> used for? For example, a customer calls in and they have X problem which the
> Admin can get with Y information? Also would any of this information be sent
> to a development team to use or is it simple customer support
> representatives that would use it?
>
> I am wondering basically what the difference in technical knowledge that
> they would have?
>
> The reason I ask is currently, the organization I work for is taking on
> a similar issue where we are trying to understand how our error handling
> should work to balance security and customer service. The stance we have
> taken thus far is to use custom error pages to present to the customer with
> a date time stamp of the time that issue occurred. The actual error is
> logged elsewhere which is encrypted and only accessible to the developers.
> When customer support receives the error a ticket is created for the
> customer and the developers who then investigate the issue.
>
> The idea is to give the customer as little information as possible while
> giving them enough information that we as developers can debug the issue.
> Also the other issue we are having to face is, by using error codes or some
> identifiable information that would tell us exactly what the error is could
> be a security risk. If an attacker is trying to exploit flaws, the error
> code they get will give them something about the system. As the code
> changes, they can format their input appropriately to discover what the
> codes mean. With that said, it is why we are using date time stamps
> and potentially other information that the user already knows.
>
> Does that help any? Also can you please provide those scenarios and I will
> be happy to help as much as I can.
>
> Thanks,
> Allen
>
> On Mon, Jul 4, 2011 at 11:53 AM, <owasp-alabama at lists.owasp.org> wrote:
>
>> I have a web application im writing, its designed for intranet use, but
>> there is no restriction to putting on the open internet.. (customers control
>> that)...
>>
>> it has many complex settings that are all controlled via an admin
>> interface..
>>
>> Many of the support issues we expect will require some debug info to be
>> logged.  We cannot however log to a file on the webserver, as the people who
>> would be gathering this info (internal tech support) would not have access
>> to the physical server, only the webui.  (think large company tech support
>> vs server admins).  all these logs will need to be in the DB, and allow
>> ADMIN access to the webui to access.  USERS will not have access to them.
>>
>> anyway, in this case are there any limitations to the kind of information
>> we should allow to be logged (apart from the obvious USER/PASS kinda
>> stuff)..?
>>
>> examples are:
>> - debug messages that report the actions and results of internal functions
>> - interaction between different systems this integrates with
>> - documenting inputs and outputs of functions, classes and routines
>> - documenting SQL structures and other SQL specific settings...
>>
>> What would this information and the logging system as discussed affect a
>> security eval of the product?
>> does it pose a security liability of the product?
>>
>> we are trying to balance supportability with security...
>>
>> thoughts, comments?
>>
>> Chris.
>> _______________________________________________
>> Owasp-alabama mailing list
>> Owasp-alabama at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-alabama
>>
>
> _______________________________________________
> Owasp-alabama mailing list
> Owasp-alabama at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-alabama
>
>
>
> _______________________________________________
> Owasp-alabama mailing list
> Owasp-alabama at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-alabama
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-alabama/attachments/20110705/9b2692f6/attachment.html 


More information about the Owasp-alabama mailing list