In my web page I make an Ajax request to a WCF service. If the service throws an error then that is passed back in the JSON. The JavaScript error handler then reveals a hidden div with a mailto URL prepopulated with my details so that team members (this is a small internal app) can send me the error including the stack trace. Here's an example resulting URL from a test run:
mailto:tttttttt#mmmmmmmmm.com?subject=potential%20seed%20save%20failed&body=Potential%20seed%20URL%20=%20unknown%0DResponse%20%3A%20%7B%22ExceptionDetail%22%3A%7B%22HelpLink%22%3Anull%2C%22InnerException%22%3Anull%2C%22Message%22%3A%22testing%22%2C%22StackTrace%22%3A%22%20%20%20at%20SavePotentialSeedSearches.WCFService.StorePotentialSeed(String%20url%2C%20String%20name)%20in%20C%3A%5C%5CTFS%5C%5CProjects%5C%5CSeeds%5C%5CPreliminaries%5C%5CSavePotentialSeedSearches%5C%5CWCFService.svc.cs%3Aline%2021%5Cu000d%5Cu000a%20%20%20at%20SyncInvokeStorePotentialSeed(Object%20%2C%20Object%5B%5D%20%2C%20Object%5B%5D%20)%5Cu000d%5Cu000a%20%20%20at%20System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object%20instance%2C%20Object%5B%5D%20inputs%2C%20Object%5B%5D%26%20outputs)%5Cu000d%5Cu000a%20%20%20at%20System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc%26%20rpc)%5Cu000d%5Cu000a%20%20%20at%20System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc%26%20rpc)%5Cu000d%5Cu000a%20%20%20at%20System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc%26%20rpc)%5Cu000d%5Cu000a%20%20%20at%20System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean%20isOperationContextSet)%22%2C%22Type%22%3A%22System.ArgumentException%22%7D%2C%22ExceptionType%22%3A%22System.ArgumentException%22%2C%22Message%22%3A%22testing%22%2C%22StackTrace%22%3A%22%20%20%20at%20SavePotentialSeedSearches.WCFService.StorePotentialSeed(String%20url%2C%20String%20name)%20in%20C%3A%5C%5CTFS%5C%5CProjects%5C%5CSeeds%5C%5CPreliminaries%5C%5CSavePotentialSeedSearches%5C%5CWCFService.svc.cs%3Aline%2021%5Cu000d%5Cu000a%20%20%20at%20SyncInvokeStorePotentialSeed(Object%20%2C%20Object%5B%5D%20%2C%20Object%5B%5D%20)%5Cu000d%5Cu000a%20%20%20at%20System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object%20instance%2C%20Object%5B%5D%20inputs%2C%20Object%5B%5D%26%20outputs)%5Cu000d%5Cu000a%20%20%20at%20System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc%26%20rpc)%5Cu000d%5Cu000a%20%20%20at%20System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc%26%20rpc)%5Cu000d%5Cu000a%20%20%20at%20System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc%26%20rpc)%5Cu000d%5Cu000a%20%20%20at%20System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean%20isOperationContextSet)%22%7D
That's 2354 characters long.
Other answers suggest that URLs above 2000 characters are a bad idea as some browsers may struggle with them. But are mailto URLs parsed in any way by the browser or are they handed immediately on to the default mail tool? If they are handed on, does anyone have data on the length of mailto URLs that various mail tool (and in particular Outlook) can handle?
As noted here
- yes the browser will parse the URL before sending it
- Safari and most email clients have no hard limit (depends on available CPU and RAM)
2015 Web Browser Testing:
Safari
705000000
2 minutes
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/601.1.56 (KHTML, like Gecko) Version/9.0 Safari/601.1.56
limited by 16GB RAM
Firefox
268435455
20 seconds
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:41.0) Gecko/20100101 Firefox/41.0
limited by maximum string length
Chrome
2097132
1 second
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
limited without explanation
IE
2029
5 seconds
Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; .NET4.0C; .NET4.0E; rv:11.0) like Gecko
limited without explanation
2015 Email Client Testing:
Mozilla Thunderbird
2097132 works in 1 second
268435455 uses 100% CPU for 2 minutes but fails to render the body and is not usable
version 38.3.0
SeaMonkey
2097132 works in 5 seconds
268435455 uses 100% CPU for a long time (more than 5 minutes)
version 2.38
Apple Mail
500000 works in 14 seconds
2097132 uses 100% CPU for a long time (more than 5 minutes)
version 8.2
Microsoft Outlook
trims to 2070 in 1 second
version 2013
Related
We scanned our website for vulnerabilities and received the message shown below.
We used Clover Security to scan the Azure Web App site.
We have already implemented the solution in web.config shared on the Internet and by Microsoft on these websites:
https://azure.microsoft.com/en-us/blog/removing-standard-server-headers-on-windows-azure-web-sites/
https://learn.microsoft.com/en-us/answers/questions/28434/azure-app-service-how-to-block-msdeployaxd-on-port.html
As discussed in the last url, I have also re-created a new resource group, app service plan and app services and redeployed on in a different US location but the error still shows on re-scan.
Any suggestion on how to fix this would be greatly appreciated?
Thank you in advance.
------------------------------ Error Message Provided ( our ip has been x'd out) --------------------------------
Category Web Application
CVE -
CVSS base score 5.0
Description Web Server Information Disclosure
Host xx.xx.xxx.xx
Threat -
Impact -
Solution -
PCI compliant No
PCI details -
Reason The vulnerability is not included in the NVD.
PCI details medium
Port 8172 / tcp
Host name No registered hostname
Host OS Windows Vista / Windows 2008 / Windows 7 / Windows 2012 / Windows Vista / Windows 2008 / Windows 7 / Windows 2012
Result
url: https://xx.xx.xxx.xx:8172/
comment: Web Server Information Disclosure detected at PORT : 8172
matched: HTTP/1.1 404 Not Found
Content-Type: text/html
Server: Microsoft-IIS/10.0
Date: Thu, 23 Jun 2022 08:20:52 GMT
Connection: close
Content-Length: 103
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
CVSS Base Score 5.0 - - AV:N/AC:L/Au:N/C:P/I:N/A:N
CVSS Temporal Score 4.3 - E:POC/RL:W/RC:C
Severity 2
Category Web Application
CVE ID
Vendor Reference
Bugtraq ID
Date Updated Jun 1, 2022
Threat The target application discloses the Web Server software version via the "Server:" token sent in HTTP response header.
QID Detection Logic:
This QID sends a GET request to the target application and determines the Web Server version disclosed in the "Server:" token.
Impact Revealing the specific software version of the server may allow the server machine to become more vulnerable to attacks against software that is known to contain security holes.
Solution Customers are advised to modify the HTTP response header of the target application to not disclose detailed information about the underlying web server. Server implementers are encouraged to make this field a configurable option.
You need to raise this as a false positive, as the failing scan is for port 8172. This is part of Azure's services infrastructure and isn't removable or editable. You might also get false positives for ports 455 and 454 on the same IP address. When you create the false positive claim, you need to let your PCI scan provider that these ports are not accessible nor for use by the general public. You will also need to "confirm" that there is no CHD (Cardholder data) being transmitted through those ports/services.
I'm building a user authentication system in Nodejs and use a confirmation email to verify a new account is real.
The user creates an account, which prompts him/her to check the email for a URL that he/she clicks to verify the account.
It works great, no issues.
What's unusual is that in testing, when I email myself (to simulate the new user process), and after I click the verify-URL, immediately afterward there are two subsequent connections to the endpoint. Upon inspection, it appears the source IPs belong to Google. What's even more interesting is that the user agent strings are random versions of Chrome.
Here's an example of the last sequence. The first one is the HTTP 200 request and the next two -- the HTTP 400s are Google. (I remove upon user verification the user's verification code from the database so that subsequence requests are HTTP 400s.)
162.158.78.180 - - [03/Jul/2020:20:35:40 +0000] "GET /v1/user/verify/95a546cf7ad448a18e7512ced322d96f HTTP/1.1" 200 70 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36" "hidden.com" "72.191.192.163" "US" "en-US,en;q=0.9"
162.158.187.117 - - [03/Jul/2020:20:35:43 +0000] "GET /v1/user/verify/95a546cf7ad448a18e7512ced322d96f HTTP/1.1" 400 28 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36" "hidden.com" "74.125.210.22" "US" "en-US,en;q=0.9"
162.158.187.117 - - [03/Jul/2020:20:35:43 +0000] "GET /v1/user/verify/95a546cf7ad448a18e7512ced322d96f HTTP/1.1" 400 28 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.122 Safari/537.36" "hidden.com" "74.125.210.8" "US" "en-US,en;q=0.9"
Now I'm using Cloudflare so the first IP address is a Cloudflare address but the second one you see is the real one [as reported by Cloudflare] ... I modified my "combined" log format in Nginx.
Anyhow, any idea what this is? Or why Google would be doing this?
It's just incredibly suspicious given the use of randomized user agent strings.
And one last note, if I inspect my console w/Chrome and go into the network tab before I click a verification link from my email, the 2 subsequent connections never come. It's like Google knows I'm monitoring ... this is just so incredibly odd that I had to ask the community. I'm thinking maybe this is an extension that's infected w/some kind of tracking, but how then do the IPs come back as Google?
New thread: https://security.stackexchange.com/questions/234241/suspicious-behavior-by-google-when-verifying-users-via-nodejs?noredirect=1#comment479497_234241
this is going to sound weird but i started having the same problem this week and i’ve been going legitimately crazy trying to figure out what’s causing it. is your desktop a windows machine? if so is it running the adobe update service? (adobeupdateservice.exe)
i have been killing processes and shutting off chrome extensions one by one and it finally stopped doing this after i killed the adobe services. i have two computers with mostly identical software installs and only one will trigger this in chrome - one difference is that the computer triggering these “cache.google.com” requests has a much newer adobeupdateservice from like two weeks ago
i have been throwing requests at it all day now and finally it’s stopped sending phantom followup requests from weird IPs
I scrapped the internet but did not find any good resource on how to create routes with a custom scheme (my-app://) with node.js.
Strictly speaking, it would not really be custom protocol, it would be http but served with another scheme.
How can I do that?
I can install any npm packages.
If it is HTTP then even though some other client application is using another scheme to connect, you will still get it as HTTP on the server side.
In fact, in the HTTP protocol you don't get the protocol scheme in the request. You get the host (hostname and port) in the Host heared and yu get the path (with query string but no fragment part) in the GET lite of the request (or POST etc.). At no point the client sends any indication of what protocol does it use, unless it's a request to a forward proxy server (but not if it's a reverse proxy).
It is your server that assumes which protocol scheme is used because it knows what protocol it speaks with on a given port. In the case that you describe of a client that uses some other protocol name in the URL but connects to your server using HTTP, your server will only need to know HTTP and the routes doesn't usually include the protocol anyway, maybe unless it's Diet.js but even then it's used in the listen argument, not in the routes.
This is an example HTTP request:
GET / HTTP/1.1
Host: localhost:3344
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/53.0.2785.143 Chrome/53.0.2785.143 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8,pl;q=0.6
The only place where it has "HTTP" is the first line defining the version of the protocol so that the client could understand the headers properly and this you would need to keep anyway so that your server could work if you want to use the built in http module or any framework in Node. If you changed that then you will have to write your own parser of the protocol.
I'm developing a tool for checking the integrity of links in a web page.
I've noticed that various Instagram URLs will return a HTTP 500 response in cases where if one were to visit the given URL in a browser one would get a HTTP 200 response accompanied by the expected resource.
This is when requesting regular Instagram URLs as one would do as a browser user and not when using the REST API.
A typical request/response using cURL:
curl -v http://instagram.com/p/YKTkxHBA-P/
* About to connect() to instagram.com port 80 (#0)
* Trying 54.225.159.246... connected
> GET /p/YKTkxHBA-P/ HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: instagram.com
> Accept: */*
>
< HTTP/1.1 500 Server Error
< Cache-Control: no-cache
< Content-Type: text/html
< Date: Tue, 15 Oct 2013 08:31:09 GMT
< Server: nginx
< Content-Length: 87
< Connection: keep-alive
<
<html><body><h1>500 Server Error</h1>
An internal server error occured.
</body></html>
* Connection #0 to host instagram.com left intact
* Closing connection #0
I did for some time get HTTP 200 responses in such cases but am now consistently getting HTTP 500 responses.
This is all specific to a given host; such URLs, even when sending requests with cURL, will return HTTP 200 responses from other machines.
Due to this being specific to the host sending the requests I suspect a form of rate limiting or request filtering by IP is going on, however I can find no documentation to the effect.
Will Instagram officially return a HTTP 500 response as above due to a given IP being denied access?
This is an IP rate limit. If you want to skip the part where you contact Instagram and wait for the monkey crew they have working over there to fix the problem, simply assign 1000 IPs to your server and loop through them randomly for your requests. You won't see anymore 500's.
Cheers.
I've received a mail from Instagram support just yesterday.
...
Hi,
We made some changes to our server configurations, can you please check if you are still seeing the 500 errors?
Thanks,
...
..well I was 100% certain that those 500ers didn't come from IG's IP rate limit because they weren't returned beforehand either.
I've been checking the logfiles and found a couple 502 (Bad Gateway) and "host unreachables", though no more 500 per se, after 2014-04-14 18:28:56 (PST).
Looks like they've finally sorted it out after nearly a month... ^_^
I had the exact same problem - unfortunately there is no way around it. This happens because of two many requests. At first I thought it was my IP or possibly my UDID until I signed into my app from my own phone and from my home IP but using a different Instagram id and it finally worked as expected again. Eventually, I could use my own ID again as time went by but with limited requests. I am not exactly sure how the algorithm works but the more time that went on the more requests I could use again.
Also, this is in real-time on an actual iPhone in an actual app - not on the iOS sim or Instagram API console, FYI.
Main Point: The request limit is based off the user (5000 requests per hour per user)...there is no IP rate limit.
Hope this helps :)
Clayton
I have the same problem. As i've rad, you have to get an extra access to API, I mean the Sandbox mode in your application does not allow you to use all the API. To get extra premissions go to client preferences, tab "premissions".
It seems to be related to curl version, I also experience the same problem with v 7.22.0 on 4 different machines 10 different ip's, while v7.30.0 and v7.19.7 are working like a charm.
Currently investigating further more.
I'm almost 100% sure this happens because the domain/IP address is blocked from the Instagram API.
Reason:
Works to get the JSON in the browser. Doesn't work to get with cURL from webservice.
I copied my exact application from my primary domain (were the application doesn't work) to another domain. Same application worked.
The strange thing is that you get a "500 Internal Error" back and not a message "Your IP is blocked".
I have an application hosted on Linux 5.5 that uses SMB and RPC calls to a Windows server to gain some data from the registry.
The problem is that when I have a look at the wireshark traces I see a response coming from the windows server stating that bind_nak reason protocol version not supported. I see that the Linux server is using Major version 5 and minor version 0. Tried with Windows 2008 server. Same problem seen. Due to this I am not able to get the data I want.
Any idea how I could decode the problem? What do I look for on the windows/linux server.
Note: - The initial to and fro using SMB protocol is successful. That is I can see in the wireshark traces that there was a negotiation of protocol, then I can see commands such as session setup andx request, session setup andx response, NT create andx request, NT create andx response etc etc.