Vraag Parseable NGINX-toegangslogbestanden met scheidingstekens


Het standaard NGINX-formaat is dit:

log_format combined '$remote_addr - $remote_user [$time_local]  '
                '"$request" $status $body_bytes_sent '
                '"$http_referer" "$http_user_agent"';

Dat is een beetje moeilijk te ontleden. Ik ben bang dat mensen injecteren " in beide verzoeken, verwijzers of user-agents.

Ik heb er over nagedacht om scheidingstekens te gebruiken en mijn eigen indeling te gebruiken |P-,| als een scheidingsteken:

log_format parsable '$status |P-,| $time_iso8601 |P-,| $http_host 
|P-,| $bytes_sent |P-,| $http_user_agent |P-,| $http_referer 
|P-,| $request_time |P-,| $request';

Niets belet echter dat gebruikers injecteren |P-,| in hun verzoeken, verwijzers of user-agents.

Ik heb dit artikel gelezen over door ASCII begrensde tekst: https://ronaldduncan.wordpress.com/2009/10/31/text-file-formats-ascii-delimited-text-not-csv-or-tab-delimited-text/

Ik denk dat dit kan worden gebruikt om deze problemen op te lossen, maar gebruikers zouden ASCII-begrenzers ook in hun gegevens kunnen injecteren.

Is er een best-practice manier om dit probleem op te lossen?


6
2018-03-27 11:59


oorsprong


Ik log JSON liever in. Het is eenvoudig te ontleden en kan worden doorgestuurd naar een logserver zoals Graylog of Kibana. - mschuett
Ik heb dat ook gedaan, maar omdat de JSON-module niet standaard is ingebouwd in de Ubuntu-repos, heb ik deze niet gebruikt. Ik heb gedaan wat ze suggereren hier. Ze vermelden een gebruiker die de user-agent instelt " om niet-geldige JSON te genereren, maar misschien verwijst de wijziging @alexeyton naar het verhelpen van dit probleem - Kasper Grubbe


antwoorden:


Er is geen probleem.

Ik ben bang dat mensen injecteren " in beide verzoeken, verwijzers of user-agents.

" wordt weergegeven als \x22

Verzoek:

$ curl 'localhost/"?"="' --header 'User-Agent: "'

regel in logboek:

[27/Mar/2014:16:14:42 +0400] localhost 127.0.0.1 "GET /\x22?\x22=\x22 HTTP/1.1" 200 "-" "\x22" "-" "/index.html"

BIJWERKEN

Van nginx changelog

Veranderingen met nginx 1.1.6 17 oktober 2011

*) Change: now the 0x7F-0x1F characters are escaped as \xXX in an
   access_log.

Veranderingen met nginx 0.7.0 19 mei 2008

*) Change: now the 0x00-0x1F, '"' and '\' characters are escaped as \xXX
   in an access_log.
   Thanks to Maxim Dounin.

14
2018-03-27 12:16



Ik zag de documentatie niet vermelden dat ze zulke tekens ontvluchten, dat is goed om te weten, bedankt voor je antwoord. - Kasper Grubbe
Ik ben niet zeker van andere personages. Dat is een goede reden om met dubbele aanhalingstekens vast te houden als stringscheidingsteken in logboeken. - Alexey Ten
Welnu, in dat geval zou ik "als scheidingsteken kunnen gebruiken. Ik zal proberen om het Nginx-project via hun mailinglijsten te contacteren en hier bij te werken. - Kasper Grubbe
@KasperGrubbe zie update - Alexey Ten
@alexeyton Bedankt! Leuke vondst! - Kasper Grubbe


Vergeet niet dat een aantal velden door het systeem worden gegenereerd, dus ook veilig zijn. Als u ervoor zorgt dat deze velden aan de linkerkant staan ​​en de hackable aan de rechterkant (http_user_agent moet aan het einde en de http_referer daarvoor, verzoek moet daarvoor zijn), kunt u ervoor zorgen dat de meeste gegevens goed zijn en door toe te voegen meer scheidingstekens voor de parser (een optionele geheel rechts) die mogelijk kan bestaan ​​zonder invoeging, dan zal uw parser records detecteren die zijn onderworpen aan invoeging.

Ook heb ik het gebruik van een tab-teken als scheidingsteken opnieuw gestart, omdat ik denk dat iemand die probeerde het in een URL in te voegen, het zou zijn ontsnapt naar een% 09


1
2018-03-27 12:14



je zou ook geen referer op serverniveau kunnen loggen, lijkt het als een optie gemist - MrMesees