Posted: Mon Mar 14, 2016 22:39 Post subject: How I solved the issue in my situation
tipstir wrote:
400 Bad Request
Cross Site Action detected!
Pink background
I had this issue with my setup. Unfortunately my issue was not rectifiable by a firmware update as there is only 1 firmware version for my router.
I have registered on this site just to pass on the solution that worked in my situation.
I triggered this issue not only because I decided to make a DNS name for my router's IP, but also because I decided to reverse proxy my router's homepage via Apache out to the internet (on a different URL)....
Obviously I had triggered the cross site scripting security, as that was pretty much exactly what I was doing.
DD-WRT picked up that the headers in my requests were not correct for the router, so it denied the request with an error 400.
Since my proxy was set with Apache, I had a rewrite rule in place already.
I had to add a little bit extra to the rewrite rule to make it all work : ProxyPreserveHost On and RequestHeader unset referer
Code:
<VirtualHost *:80>
ServerName my.server.com
DocumentRoot "/var/www/my.server.com/"
RequestHeader unset referer
ProxyPreserveHost On
ProxyPass / http://ADDRESS/
ProxyPassReverse / http://ADDRESS/
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
</VirtualHost>
Prior to that, I got the bad requests.
Obviously, I had tried a few different ways to solve it before I got to this solution. Some solutions got past the 400 error, but broke the CSS in the process.
This way ensured that my browser not only didn't get a 400 error, but all the CSS loaded correctly too (reverse proxies and relative links do not like each other it seems!)
Posted: Sat Oct 22, 2016 23:26 Post subject: "Connection was reset"
DD-WRT "Connection was reset" error in Firefox
or DD-WRT "Cross site action detected" error in Firefox
or DD-WRT "400 Bad Request" error in Firefox
while Save / Saving or Apply / Applying in Setup / Settings but it works in Chrome or Internet Explorer it may be because your Firefox browser is not sending Referrer Headers properly. DD-WRT strictly checks the headers for security reasons. Here's how I fixed it:
* The Firefox config setting "Network.http.sendRefererHeader" was set to "0" instead of the default which is "2". To change this type "about:config" into the Firefox address bar, then search on "Network.http.sendRefererHeader". Right-click to change.
* Other Firefox add-ons related to Privacy, Stealth, Headers or Referrers can also cause this problem. Try disabling them or try "Help -> Restart with Add-ons disabled"
The real fix is to add "no_crossdetect=1" into your NVRAM. Why that is not a DD-WRT default I have no idea!
Thanks for that info; this is what BS said about it...
BrainSlayer wrote:
this feature is introduced in r14962. to prevent bad configs, i will not implement it as gui configurable feature
http://svn.dd-wrt.com/ticket/1483#comment:1
That means anyone needing this and running 14929 (or 14896, which nobody should be using) or older builds, needs to update to at least (Peacock recommended) build 15962. Which was the issue here, in fact. _________________ #NAT/SFE/CTF: limited speed w/ DD#Repeater issues#DD-WRT info: FAQ, Builds, Types, Modes, Changes, Demo#
OPNsense x64 5050e ITX|DD: DIR-810L, 2*EA6900@1GHz, R6300v1, RT-N66U@663, WNDR4000@533, E1500@353,
WRT54G{Lv1.1,Sv6}@250|FreshTomato: F7D8302@532|OpenWRT: F9K1119v1, RT-ACRH13, R6220, WNDR3700v4
Seems this may not be working for the Netgear R6300v2 build 38840. I have no_crossdetect set to 1 in NVRAM, but it still pops the error page when I go through my link.
I know this is not current, but it was stable for this router. It originally was a Charter-firmware router that I went through steps to reset it's board ID to make it a non-Charter version, and load the normal Netgear firmware. I know it's had some stability issues in the past, and considered changing it back, but build 38840 has been rock solid on it and I didn't want to give that up just yet.
I do know this worked on a previous dd-wrt build, just don't remember which one.
Anyway, seems we still have to keep an eye on this functionality so we can keep the router working the way we want it to. And now I'm off to figure out what build to try next.
Still not working on 40009. Need to get the latest and see if that works, then I'm going to either re-open the bug or enter a new one. This is one annoyance I could do without.
I loaded 41075 on my R6300v2. Did not reset the settings as I've rarely had issues with that. Everything else seems working fine.
But, it initially was still blocking with the cross site action block. The carried over settings from 40009 had the no_crossdetect already set to 1.
So I set it to 0, rebooted, and verified it still blocked me. Then set it to 1 and rebooted, now it is working. I no longer get the block and go straight to the router pages, like it should.
I didn't change anything else in the config across the reboots after 41075 was loaded. Just the no_crossdetect setting was changed.
It's possible this was not broken for as long as I thought it was, but I do recall earlier this year (before my June post in this thread) that I did a clean setup on another R6300v2 with the same build as this router and it didn't work there either.
Oh well, this build looks stable and the no_crossdetect is working, so I'm good.
Others that can't get this to work, you might try setting no_crossdetect to 0, reboot, then set to 1 and reboot again. Might make it work for you.
for those, who have the same issue accessing DD-WRT machine from another website: I'm using ref="noopener noreferrer" in the links to avoid it (I have a network map located on one local webserver with clickable objects on it and this workaround serves well).
[/b]