[Owasp-leaders] Application Security Logging Cheat Sheet

Colin Watson colin.watson at owasp.org
Wed Apr 25 20:15:07 UTC 2012


Eoin

Thanks for the additional feedback. I have updated the page... changes:

    https://www.owasp.org/index.php?title=Logging_Cheat_Sheet&action=historysubmit&diff=128584&oldid=128583

I hope this captures your intent.

Colin

On 24 April 2012 00:07, Eoin <eoin.keary at owasp.org> wrote:
> More feedabck,
>
> Links to log attacks/CLRF would be good also to demo?
>
> Mime type of logs if viewed by web scraper needs to be text to help prevent XSS?
>
>
>
> Eoin Keary
> BCC Risk Advisory
> Owasp Global Board
> +353 87 977 2988
>
>
> On 23 Apr 2012, at 22:43, Colin Watson <colin.watson at owasp.org> wrote:
>
>> Eoin
>>
>> Thanks.
>>
>>> May I ask (I only scanned the doc) have you included logging of input from external sources
>>
>> I mention these other possible sources (so far):
>>
>> "* Client software e.g. actions on desktop software and mobile devices
>> in local logs or using messaging technologies, web browser such as
>> using Content Security Policy (CSP) reporting mechanism
>> * Network firewalls
>> * Network and host intrusion detection systems (NIDS and HIDS)
>> * Closely-related applications e.g. filters built into web server
>> software, web server URL redirects/rewrites to scripted custom error
>> pages and handlers
>> * Application firewalls e.g. filters, guards, XML gateways, database
>> firewalls, web application firewalls (WAFs)
>> * Database applications e.g. automatic audit trails, trigger-based actions
>> * Reputation monitoring services e.g. uptime or malware monitoring
>> * Related applications e.g. fraud monitoring, CRM"
>>
>>> and validation of such?
>>
>> The cheat sheet says:
>>
>> "The degree of confidence in the event information has to be
>> considered when including event data from systems in a different trust
>> zone. Data may be missing, modified, forged and could be malicious –
>> it must always be treated as untrusted data. Consider how the source
>> can be verified, and how integrity and non-repudiation can be
>> enforced."
>>
>> and:
>>
>> "* Perform input validation on event data from other trust zones to
>> ensure it is in the correct format (and consider alerting and not
>> logging if there is an input validation failure)
>> * Perform sanitization on all event data to prevent log injection
>> attacks e.g. carriage return, line feed and delimiter characters (and
>> optionally to remove sensitive data)
>> * Encode data correctly for the output (logged) format
>> * If writing to databases read, understand and apply the SQL
>> injection cheat sheet"
>>
>>
>>> Also log scrapers and encoding data to prevent log scraper attacks.
>>
>> I'm not sure what you mean here? I discuss access control, and for web
>> applications, not storing logs in web-accessible locations.  Should we
>> add something more?
>>
>>
>>> (I know this is also crossing into other realms)
>>> Just a thought :)
>>
>> All thoughts welcome.
>>
>> Colin
>>
>>
>>> On 23 Apr 2012, at 21:04, Jim Manico <jim.manico at owasp.org> wrote:
>>>
>>>> Our good friend Colin Watson just finished the first version of the
>>>> (Security) Logging Cheat Sheet.
>>>>
>>>> https://www.owasp.org/index.php/Logging_Cheat_Sheet
>>>>
>>>> Please check it out! Any feedback is greatly appreciated.
>>>>
>>>> And the cheating continues.... We have several more cheat sheets in the
>>>> hopper to be released soon.
>>>>
>>>> Aloha!
>>>>
>>>> --
>>>> Jim Manico
>>>>
>>>> Connections Committee Chair
>>>> Cheatsheet Series Product Manager
>>>> OWASP Podcast Producer/Host
>>>>
>>>> jim at owasp.org
>>>> www.owasp.org
>>>> _______________________________________________
>>>> OWASP-Leaders mailing list
>>>> OWASP-Leaders at lists.owasp.org
>>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders


More information about the OWASP-Leaders mailing list