CODEWITHSUNDEEP
phphttp-redirectcurlhttp-headersiptables
Mike
Mike

Reputation: 1988

PHP Redirect, Iptables, and data after connection closed

This is an odd one. We recently found a 3-month old bug in our code where we post a 302 redirect header after a print_r. As a result, the browser would receive the string, and not redirect to the next page.

This print_r had been in production for an exceptionally long period of time and no one has mentioned it, which led us to believe it was a config difference on production and development. The latest change was a change to IPtables, and when we reverted the change, it seemed to fix the issue.

Oddly, we can not reproduce the issue for our own edification. Which brings me to the question, can IPtables even affect a 302 redirect? Much less, care if data was sent before the headers? From my research, no, but I wanted to ping the all-knowing ones first.

The person who made the IPtables change a few days ago (which we reverted and somehow solved the issue) says these are the offending entrys:

ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

The first entry was what it has been, and the second entry is what he changed it to that broke the site. Reverting to the first entry 'fixed it.' First, I know, super secure...it's a local dev box.

I tried curling the url (that is now working, because we can't break it) to see what I could see, and I noticed the second part of this question. Curl registers * Closing connection #0 before the print_r comes in, and when it does come in, it comes in under my prompt:

< HTTP/1.1 302 Found
< Date: Thu, 18 Apr 2013 16:14:55 GMT
< Server: Apache/2.2.3 (Red Hat)
< X-Powered-By: PHP/5.3.3
< location: app.php?cart_item_id=1234567
< X-UA-Compatible: IE=Edge
< Content-Length: 17
< Connection: close
< Content-Type: text/html; charset=UTF-8
<
* Closing connection #0
<pre>before</pre>[user@localhost ~]$

So.... Yeah. Any thoughts? I mean, all is fine now, I would just like to know why...

Bass: Ok, but when I curl, yahoo.com I get this:

[user@localhost~]$ curl yahoo.com -v
* About to connect() to yahoo.com port 80 (#0)
*   Trying 206.190.36.45...
* connected
* Connected to yahoo.com (206.190.36.45) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.24.0 (x86_64-redhat-linux-gnu) libcurl/7.24.0 NSS/3.13.5.0 zlib/1.2.5 libidn/1.18 libssh2/1.2.2
> Host: yahoo.com
> Accept: */*
>
< HTTP/1.1 301 Redirect
< Date: Fri, 19 Apr 2013 13:28:10 GMT
< Connection: close
< Server: YTS/1.20.13
< Cache-Control: no-store
< Content-Type: text/html
< Content-Language: en
< Location: http://www.yahoo.com/
< Content-Length: 211
<
<HEAD><TITLE>Redirect</TITLE></HEAD>
<BODY BGCOLOR="white" FGCOLOR="black">
<FONT FACE="Helvetica,Arial"><B>
 "<em>http://www.yahoo.com/</em>".<p></B></FONT>

<!-- default "Redirect" response (301) -->
</BODY>
* Closing connection #0
[user@localhost~]$

I get the * Closing connection #0 After all content. What is the difference?

As for the iptables rule, there are other allows, port 80, etc, that follow after that rule. So I guess.... bur... well I don't know...

Upvotes: 1

Views: 346

Answers (2)

fred
fred

Reputation: 192

As Bass says, headers will be sent before print_r. Moreover, iptables will not do "Deep packet inspection", so it cannot see the content of your message.

Difference of your two line is that the first one allow all packets from any ip to any ip and the second one allow only packet for already established connection.

If no rule allows packets for new connection. none of the packet will be flow thought the rule allowing established connection. (more information on connection tracking ?)

Upvotes: 1

Bass Jobsen
Bass Jobsen

Reputation: 49054

See http://php.net/manual/en/function.print-r.php the result of print-r is buffered unless you set the return parameter to true. So print_r do not trigger to send the HTTP headers. Then read http://php.net/manual/en/function.header.php: The HTTP status header line will always be the first sent to the client, regardless of the actual header() call being the first or not. The status may be overridden by calling header() with a new status line at any time unless the HTTP headers have already been sent.

Upvotes: 0

Related Questions