POST-Daten bei Apache loggen mit "mod_security"?

  • Thread starter Thread starter jmar83
  • Start date Start date
J

jmar83

Guest
Hallo zusammen

Geht scheinbar nicht: https://stackoverflow.com/questions/989967/best-way-to-log-post-data-in-apache


Inhalt der Datei:

```
--ad153920-F--
HTTP/1.1 301 Moved Permanently
Location: https://www.abc.com/1/2/3/4.php
Content-Length: 352
Content-Type: text/html; charset=iso-8859-1

--ad153920-H--
Stopwatch: 1575040538302299 1123 (- - -)
Stopwatch2: 1575040538302299 1123; combined=725, p1=563, p2=0, p3=44, p4=50, p5=68, sr=119, sw=0, l=0, gc=0
Producer: ModSecurity for Apache/2.9.3 (http://www.modsecurity.org/); CWAF_Apache.
Server: Apache
Engine-Mode: "ENABLED"

--ad153920-Z--

--5e6f4145-A--
[29/Nov/2019:16:15:42 +0100] XeE2Hsx61tOrJFm6gWAQgAAAAAc 193.5.121.19 58716 81.169.200.216 443
--5e6f4145-B--
POST /1/2/3/4.php HTTP/1.1
Host: abc.com
Accept: */*
Content-Length: 77
Content-Type: application/x-www-form-urlencoded

--5e6f4145-F--
HTTP/1.1 301 Moved Permanently
Location: https://www.abc.com/1/2/3/4.php
Content-Length: 352
Content-Type: text/html; charset=iso-8859-1

--5e6f4145-H--
Stopwatch: 1575040542453566 1072 (- - -)
Stopwatch2: 1575040542453566 1072; combined=698, p1=538, p2=0, p3=45, p4=48, p5=67, sr=117, sw=0, l=0, gc=0
Producer: ModSecurity for Apache/2.9.3 (http://www.modsecurity.org/); CWAF_Apache.
Server: Apache
Engine-Mode: "ENABLED"

--5e6f4145-Z--

```


Was soll ich damit?? ;-) Nix mit POST-Felder...

Server ist Plesk Obsidian 18 (neuste Updates) unter Ubuntu LTS 18...


Danke für die Feedbacks.
 
Und "Content-Type: text/html; charset=iso-8859-1" stimmt schon mal gar nicht...

Die Seite https://fabianstiehle.com/mimetype/ gibt mir das aus, was Fakt ist, nämlich "application/json":

```
header("Content-type: application/json; charset=utf-8");
```
 
Vielen Dank.

Das Problem war dass der Client falsch lief, https war damit (C-Programm) nicht möglich. Der Webserver ist so eingestellt, dass wenn man http://... aufruft dass dann eine 301-Weiterleitung per Plesk-Konfig erfolgt.

Der http-Client vom C-Programm lief damit bis kurz vor dem Redirect von http zu https, dann brach er ab.

"Und "Content-Type: text/html; charset=iso-8859-1" stimmt schon mal gar nicht..." -> keine Ahnung was das ist, ich werde es dann mit einem https-Client versuchen. Es kann sein, dass Plesk VOR dem konfigurierten Redirect http->https alles mit diesem content-Type ausliefert.

Wäre zwar ein wenig schräg, kann aber durchaus sein. Mal schauen.

Wünsche ein schönes Wochenende! :-)
 
jmar83 said:
"Und "Content-Type: text/html; charset=iso-8859-1" stimmt schon mal gar nicht..."
Click to expand...
Was ist denn das Problem?
Die Redirects haben den als Standard gesetzten Content-Type von Apache. Die 301/302-Seite für den Browser braucht ja einen Content-Type-Header.
Und? Was macht das nun bei dir kaputt?
 
jmar83 said:
Vielen Dank.
Das Problem war dass der Client falsch lief, https war damit (C-Programm) nicht möglich. Der Webserver ist so eingestellt, dass wenn man http://... aufruft dass dann eine 301-Weiterleitung per Plesk-Konfig erfolgt.
Der http-Client vom C-Programm lief damit bis kurz vor dem Redirect von http zu https, dann brach er ab.
Click to expand...

Das Problem ist vermutlich der 301-Redirect. Verwende stattdessen 307 oder 308 ;-)
Bei 301 folgt der Client der Weiterleitung, wechselt dabei aber in der Regel auf GET als Methode (sollte so aus den Logs auch hervorgehen) und dabei gehen dann natürlich die POST-Daten verloren.
Wenn 307 oder 308 verwendet wird, weist dies den Client an, der Weiterleitung zu folgen und den ursprünglichen Request am Ziel noch einmal genau so auszuführen.

Du könntest eine Regel definieren die für Anfragen mit der POST-Methode statt 301 stattdessen 307 liefert, dann sollten die Anfragen korrekt am Ziel ankommen. Oder, besser noch, du hinterlegst die HTTPS-URI im Client ;-)
 
Das Problem hatte ich mal anders herum. Formular sendet die Daten via POST-Request und am Ende hab ich einen redirect zum Index ausgegeben (Serverseitig). Nginx meckert dann rum, dass die Route für POST-Request nicht vorhanden ist. Ich habs dann richtig gemacht und ein Template angelegt, dass bei GET und POST ausgeliefert wird.

Eigentlich wollte ich das ganz einfach handhaben: Fire and forget
Das mit dem 307er ist aber auch interessant. Wusste ich gar nicht.

Da würde ich eher so vorgehen, dass von Anfang an die richtige Route für den POST-Request geliefert wird und nicht irgendeine Route,
die dann nochmal umgeschrieben werden muss. Wenn du mal den Code debuggen musst und zu viele Umleitungen drin hast, wird das Problem komplexer.
 
You must log in or register to reply here.
Back
Top