[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:40:06 EDT 2011


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-alabama/attachments/20110704/0b242b34/attachment.html 


More information about the Owasp-alabama mailing list