[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
Mon Jul 4 13:09:19 EDT 2011


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-alabama/attachments/20110704/b7df823f/attachment.html 


More information about the Owasp-alabama mailing list