We have a PHP site hosted from an Apache server.
We have a .NET site hosted from a windows server.
Both are internal, and inside our domain.
When a user accesses the PHP site, it checks if your username has been sessioned. If not, it does an ajax GET postback to the .NET "GetUsername.aspx" page. The GetUsername.aspx page simply outputs Request.ServerVariables("LOGON_USER")
The .NET site requries windows authentication to be enabled in IE. All of our users use IE8.
In order for our PHP site to request data from the .NET site, a setting "Access data across domains" must be enabled... and it is.
In order for our .NET site to get your username, "Enable Integrated Windows Authentication" must be nabled... and it is.
Both the .NET site, and the PHP site are intranet sites. If you go to Internet Options -> Local Intranet -> Sites -> Advanced, both sites are in the list.
At this line: xmlhttp.open("GET","http://intranet.MySite.vmv/IS/GetUsername.aspx",false);
A javascript error occurrs with the message "Error: Access is denied."
If i type that same .NET page into the browser url... it loads just fine, and shows her username.
The confusing thing about all this, is that our policy updates (pushed out on every login) set all of these settings. I've verified all the above settings are the same on my browser as they are on this users. Both of us are within the same domain.
Any ideas of some other setting that could be causing this?
Thanks!
EDIT
here are the results from firebug... doesnt seem to be very helpful, just shows me what we already knew.
http://intranet.MyCompany.vmv/IS/GetUsername.aspx
401 Unauthorized
20ms
login (line 103)
HeadersResponseHTML
Response Headers
Content-Length 1656
Content-Type text/html
Date Mon, 09 Apr 2012 16:15:33 GMT
Server Microsoft-IIS/6.0
WWW-Authenticate Negotiate NTLM
X-Powered-By ASP.NET
Request Headers
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept-Encoding gzip, deflate
Accept-Language en-us,en;q=0.5
Connection keep-alive
Host intranet.MyCompany.vmv
Origin http://192.168.1.2:10078
Referer http://192.168.1.2:10078/login
User-Agent Mozilla/5.0 (Windows NT 5.1; rv:8.0.1) Gecko/20100101 Firefox/8.0.1
Well... the issue appears to be with IE7. Somehow this user's version was not upgraded with everyone else. Once we upgraded her to IE8 it worked as expected.
Related
Sending the following form ends with a single character # shown in the MS Edge browser(Microsoft Edge 42.17134.1.0, Microsoft EdgeHTML 17.17134) and we can expect the final result should be OK!. The expected result is shown in other popular browsers. Wrapping the form with the correct HTML5 skeleton with Doctype etc. does not help. Why can some particular text not be sent via the form? Well, to be strict it can as long as I do not touch $_POST or I do not want to include this meta tag on my webpage where the form is sent. I can access the post data via php://input and everything is there in a raw but this is not a solution.
The issue was found in my own content management framework where some tags(including meta tags) are sent via the form to the PHP script.
<?php
if(isset($_POST['test'])){
echo "OK!";
} else{
echo '
<form action="/" name="template" method="post" accept-charset="UTF-8">
<textarea name="test"><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></textarea>
<input type="submit" />
</form>
';
}
?>
Naturally, the source code is saved with UTF-8 as well. Please, drag me away from this path in case I am doing something prohibited or potentially wrong. Eventually, I want to send the complete HTML head section via POST method.
Here are my questions:
Why text including <meta charset="UTF-8" /> cannot be properly sent using post method? Here, there is no question about the processing of the data via PHP script.
Is there any reason to search for the issue not in the source code but in web server installation? But, if yes why then it works with other browsers?
Can the HTTP requests be for some reason significantly different what might cause the described issue?
From where comes # can it be from the web server or the edge browser?
I am using XAMPP 7.2.4 on Windows 10.
Not everything should be allowed to send with the form by a user, but any tag is not a reason to be refused by a browser or httpd server.
The web server could reject some request, especially along the loaded mod_rewrite module with not a proper configuration,
...but what is the point of writing the # instead of an error message.
The main fear is that the HTTP requests might be different, maybe some mechanism against XSS incidentally will catch something? But as the life shown the issue here was somehow connected to cache, default content language and saved cookies.
The original issue from the question is related only to XAMPP <=> MS Edge and it has nothing to do with PHP scripts or UTF-8 encoding. It is established in the community that the meta tag with charset should be used as a safety mechanism, but what is not to be expected is that this meta tag might potentially have the influence on showing the website's content or just #. It should be strongly stressed that a similar issue is not appearing with other tags. The simplest case in which the scenario could be repeated is with the GET method by sending form data even to the HTML file.
http://127.0.0.1/?data=%3Cmeta+http-equiv%3D%22%22+%2F%3E
The other decent installations of Apache server have no such issues(I have tried apachelounge on Windows and Apache installations on different linux distributions). Therefore, I claim that reproducing the issue might be difficult and potentially can be the installation specific.
The simplest solution is to use a different version of XAMPP or other implementation of the httpd server.
For those, curious as I am, still, it is not explained why the XAMPP server has the issue with requests only from MS Edge. The typical HTTP request
GET /?data=%3Cmeta+http-equiv%3D%22%22+%2F%3E HTTP/1.1
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: pl,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1
seems not to has any unconventional stuff. There is an obvious User-Agent difference with MS Edge
GET /?data=%3Cmeta+http-equiv%3D%22%22+%2F%3E HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/17.17134
Accept-Language: pl-PL
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Upgrade-Insecure-Requests: 1
Accept-Encoding: gzip, deflate
Host: 127.0.0.1
Connection: Keep-Alive
Cookie: PHPSESSID=*********
and the Cookie, and the Accept-Language: pl-PL only. To my surprise, it turned out that cleaning of the browser data solved my issue.
I have just set up a MediaWiki 1.29.0 page on an AS400 IBM i machine. I am using MariaDB as a database. I am using PHP 5.5.37
Every time I try to log into an account, I get the error:
There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again.
Obviously, the behavior I'm looking for is to log in.
I've tried:
changing $wgMainCacheType and $wgSessionCacheType to various permutations of CACHE_NONE, CACHE_ACCEL, CACHE_DB, and CACHE_ANYTHING.
creating a tmp directory and setting its permissions.
rebuilding my LocalSettings.php file.
setting session.referer_check=off in php.ini
I've checked and I know my cookies are enabled (I'm able to call document.cookie; and get data back).
This question has been asked before here, and the linked questions within, but no solutions fixed my problem. They also deal with an older version of WikiMedia, though I don't know if that makes a difference in this instance.
EDIT: I am also getting the same behavior when I try to create a new account. However, I am able to navigate the wiki, create pages, and edit pages without any sort of error.
Here is my request header:
Cache-Control: private, must-revalidate, max-age=0
Connection: close
Content-language: en
Content-Type: text/html; charset=UTF-8
Date: Thu, 10 Aug 2017 13:48:36 GMT
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Link: </<path>/resources/assets/logo.png?88d75>;rel=preload;as=image
Server: Apache
Set-Cookie: ZDEDebuggerPresent=php,phtml,php3; path=/
Set-Cookie: <wikiname>_session=n7gs0ct99ck5i2juq0togto9q7bfou6u; path=/; secure; httponly
Transfer-Encoding: chunked
Vary: Accept-Encoding,Cookie
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Powered-By: PHP/5.5.37 ZendServer/8.5.5
X-UA-Compatible: IE=Edge
Here is my response header:
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding:gzip, deflate
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Cookie:ZDEDebuggerPresent=php,phtml,php3
Host:tdidev:10080
Referer:http://<wikiepath>/index.php?title=Special:UserLogin&retirnto=Main+Page
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36
I've finally found the issue to my problem. By default, MediaWiki passes the <wikiname>_session cookie with the secure flag set. Taken from OWASP:
The secure flag is an option that can be set by the application server when sending a new cookie to the user within an HTTP Response. The purpose of the secure flag is to prevent cookies from being observed by unauthorized parties due to the transmission of a the cookie in clear text.
To accomplish this goal, browsers which support the secure flag will only send cookies with the secure flag when the request is going to a HTTPS page. Said in another way, the browser will not send a cookie with the secure flag set over an unencrypted HTTP request.
So my MediaWiki installation correctly creates and caches a session token, and it even still passes it through the response header. However, since my browser sees an http instead of https, that's as far as the token gets. The Set-Cookie line is simply ignored.
There is a setting in php.ini called session.cookie_secure, but MediaWiki ignores this flag.
Instead, the solution was to add this line to the bottom of my localSettings.php file:
$wgCookieSecure = false;
I had something similar happen on a different application, when the sessionId was being updated out of sequence.
So normally you request a login form, and it creates a session with a sessionId, and stores this somewhere.
Then you submit the form, it ties that into the original sessionId, checks your authentication, and either logs in the original session, or creates you a new one, and updates yours (normally with a HTTP Set-Cookie command you can see in the Network log).
But you can follow everything, by looking at the sessionId in your current cookies, and any token on the form (to prevent replays), and checking it against either your /tmp/php-session-xxx file (maybe in /var/lib/php) or whatever database it's storing the session in.
What tipped me off to my problem was identifing that by the time I was about to submit a form, with a particular sessionid, that sessionid, was no-longer valid. Hence I failed the replay checks, and I got an error similar to yours. It turned out in my case it was to do with the databases replicating in a way that didn't match how they were being accessed downstream so I could attempt to access a session, that hadn't been created yet.
Looking at all your code, the sessionIds don't match. wpTokenLogin starts with 510a85 but your wiki session in SetCookie starts with n7gs0c and in your log it talks about 6ov933... So assuming you copied/pasted from different attempts, you need to run through it yourself from a clean state and check that everything looks like it's using the same session. If not, try to figure out what's happening to the session you have (if it's created/changed) or why you're not getting the right one, if it's created but never passed out to you properly.
That said, I just took at look at the client side of logging into our own inhouse version of mediawiki, and wpLoginToken, wikidb_session and JSESSIONID don't match either (although I'd expect one of them to show up in the wiki log, which I don't have access too).
If you have to, grep the source for the error message you're finding, and insert error_log(__FILE__.':'.__LINE__.' '.var_export(debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS), true)); to find out work back up the stack, to see what didn't match, to generate the error.
This is an ongoing problem with MediaWiki, and is the result of your password being incorrectly entered, or MediaWiki failed to write SOMETHING during the login process (database, cookie, disk file, whatever). In my case, I was using the $wgReadOnly variable to make the wiki read-only. I found that I had to use $wgMainCacheType = CACHE_MEMCACHED for my system to work properly.
See: https://www.mediawiki.org/wiki/Manual:Memcached
Normally when a publicly-accessible directory requires basic HTTP authentication, the value of $_SERVER['HTTP_AUTHORIZATION'] and/or $_SERVER['REMOTE_USER'] (or $_SERVER['PHP_AUTH_USER'], etc) will be set and accessible to PHP once a valid username/password combination have been provided to the server.
For example, if http://www.example.com/members requires basic authentication, and a user successfully authenticates using the credentials myusername and mypassword by manually typing http://myusername:mypassword#www.example.com/members into their browser, the value of $_SERVER['HTTP_AUTHORIZATION'] would be something like:
Basic bXl1c2VybmFtZTpteXBhc3N3b3Jk
... and the value of $_SERVER['REMOTE_USER'] would simply be:
myusername
However if authentication is not required in the same directory, but the URL is still visited with the username/password inside of it, the values of the username/password don't seem to be set anywhere (running PHP 5.3.10 as CGI/FastCGI on Apache/2.2.22).
From within PHP (and/or .htaccess if necessary), when no authentication is required, is there a way to retrieve the values of the username (and/or password) that have been provided by a visitor who manually added them to the URL?
TLDR; As far as I can see that information is never sent to server so I claim it's not possible.
The way http authentication works if you have it set is that server sends a request for user/pass if it's not already set, and browser then adds that information in encoded form to a Authorization header and sends it to the server along with the request.
As specified in RFC 2617, describing Basic and Digest authentication mechanisms For basic authentication, server sends HTTP 401 Not Authorized status and WWW-Authenticate header fields to request this information. (RFC 2617, Access Authentication Framework)
With tests one can see that if authentication is never configured on the server to be required, server won't request authentication information from browser, and browser won't add user/pass information into the request. RFC does not mandate browser (user agent) to not pass that information, but says instead
A user agent that wishes to authenticate itself with an origin
server--usually, but not necessarily, after receiving a 401
(Unauthorized)--MAY do so by including an Authorization header field
with the request.
In practice, if you watch the sent headers you can see that if this information is requested by the server, it's sent in encoded form using Authorization header like specified by the RFC. However, if you're not using any authentication the request you send just doesn't seem to contain that information in any form. I've confirmed this with IE, Firefox and Chrome browsers myself.
If you want to test this yourself for your setup, this can be done for example using netcat like this:
First, run netcat on your server:
nc -l 8888
Then issue a request from your browser to http://testvalue:testvalue#yourdomain:8888/
As a result, observe from netcat output all the information that get sent to server, something like this:
GET / HTTP/1.1
Host: yourdomain:8888
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
There is no information about user or password anywhere. I claim that unless the server requests it, it won't be there.
The addition of user and password in a url using http(s)://user:pass#site.com has been disabled by at least Internet Explorer for several years now, as far as i know.
https://support.microsoft.com/en-us/kb/834489
So I am not sure if what you are trying to reach is even usefull. I think the browsers dont even pass that part of the url on anymore.
If a logged in user navigates to a certain area of the site which is to use WebSockets, How can I grab that session Id so I can identify him on the server?
My server is basically an endless while loop which holds information about all connected users and stuff, so in order to grab that id I figured the only suitable moment is at the handshake, but unfortunately the handshake's request headers contain no cookie data:
Request Headers
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.5
Cache-Control: no-cache
Connection: keep-alive, Upgrade
DNT: 1
Host: 192.168.1.2:9300
Origin: http://localhost
Pragma: no-cache
Sec-WebSocket-Key: 5C7zarsxeh1kdcAIdjQezg==
Sec-WebSocket-Version: 13
Upgrade: websocket
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:27.0) Gecko/20100101 Firefox/27.0
So how can I really grab that id? I thought I could somehow force javascript to send cookie data along with that request but any self-respecting website in 2014 will have httpOnly session cookies so that wont work out. Any help is greatly appreciated!
Here's a link for the server I'm using: https://github.com/Flynsarmy/PHPWebSocket-Chat/blob/master/class.PHPWebSocket.php (thanks to accepted answer)
http only cookies as well as secure cookies work fine with websocket.
Some websocket modules have chosen to ignore cookies in the request, so you need to read the specs of the module.
Try: websocket node: https://github.com/Worlize/WebSocket-Node.
Make sure to use the secure websocket protocol as wss://xyz.com
Update:
Also, chrome will not show the cookies in the "inspect element" Network tab.
In node try dumping the request, something like:
wsServer.on('request', function(request) {
console.log(request);
console.log(request.cookies); // works in websocket node
}
If you see the cookies somewhere in the log...you've got it.
If you're using secure-only cookies, you need to be in secure web sockets: wss://
Update2:
The cookies are passed in the initial request. Chrome does not show it (all the time) as sometimes it shows provisional headers which omits cookie information.
It is up to the websocket server to do 'something' with the cookies and attach them to each request.
Looking at the code of your server: https://github.com/Flynsarmy/PHPWebSocket-Chat/blob/master/class.PHPWebSocket.php I do not see the word "cookie" anywhere, so it is not being nicely packaged and attached to each websocket connection. I could be wrong, that's why you might want to contact the developer and see if the whole header is being attached to each connection and how to access it.
This I can say for certain: If you're using secure cookies then cookies will not be transmitted unless you use the secure websocket wss://mysite.com. Plain ws://mysite.com will not work.
Also, cookies will only be transmitted in the request if the domain is the same as the webpage.
Im using a script from this guy
A. Valums http://valums.com/ajax-upload/
Everything is fine until the file has finished uploading and i get a 406 error on the firebug(ONLY). when i right click the link on firebug and open in new window, the file does exist and does what i expect it to do.
the page on firebug says
Not Acceptable
An appropriate representation of the requested resource upload.php could not be found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
but when i see the page on a new tab it works fine and returns the right thing, that script on A. Valums has ajax requests btw
UPDATE
Host www.example.com
User-Agent Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language en-gb,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive
Content-Type application/octet-stream
Referer http://www.example.com
Content-Length 192378
Cookie
Look at the HTTP headers. Your JavaScript is likely adding an Accept header that the server thinks it doesn't have a suitable type of data to respond with.
It was a server error.something called "mod_security" which needs to be disabled and I have no clue what it is but ask your hosting provider they should know about it if you experience the problem :)