I had a recent issue in my server-side code, where an unexpected http query value was coming through. Upon inspection of the logs, I see that my URL has had the following text appended to it:
\" and \"x\"=\"x
Thus the normal url: something.com/foo?test=true has been rewritten to something.com/foo?test=true\" and \"x\"=\"x.
I assume this is some sort of test to see if an exploit exists on my server. This is very difficult to Google due to the characters involved, and the only results I could come up with was a log file that also appeared to have the exact same text appended to a URL.
Anyone have any info on what this is trying to exploit? My service is a US-only service (providing local community information), and the IP address from which this request came from is 31.177.95.9, which unsurprisingly is a Russian IP address.
Related
I have configured my Liferay 7 site with a terms of use web content document. It works perfectly when new users log in for the first time.
However, I need to be able to provide a link to review the terms of use. The only thing I see is in the Liferay Portal struts-config.xml file, which is "/portal/terms_of_use". But this link appended to my hostname is not working. I get a "Not Found" error page ("The requested resource could not be found.").
Am I using the wrong URL? I've tried searching for what the URL would be and have not found anything, which is surprising since I would think this is a common requirement.
With the routing of web-stuff to OSGi bundles, there's no longer any top-level URL that can be specified this way (there may never have been one). However, there is a way to get to it:
http://localhost:8080/c/portal/terms_of_use requires login, but results in the (in my case unconfigured) terms of use. The /c within the URL targets struts (and maybe something else - the /portal within targets a certain bundle (portal-web in this case)
I was trying to do some simple authorization for ameritrade's developer platform. I was attempting.
According to the platform, the Endpoint I need to access is is:
https://auth.tdameritrade.com/auth?response_type=code&redirect_uri={uri}&client_id={client_id}}%40AMER.OAUTHAP
https://developer.tdameritrade.com/content/simple-auth-local-apps
When looking at the client_id, for the dev application, I was noticing that they may actually be referencing the Applications, Consumer Key instead? So i did just that, but when attempting to query the information, it returns: A third-party application may be attempting to make unauthorized access to your account. The reason why i think it is the consumer key, is listed at: https://developer.tdameritrade.com/content/getting-started
So I ended up doing something like:
from urllib.parse import urlencode, quote_plus
url = "https://auth.tdameritrade.com/auth?response_type=code&redirect_uri={uri}&client_id={client_id}}%40AMER.OAUTHAP".format(
uri=urlencode("http://localhost", quote_via=quote_plus),
client_id="JHBDFGJH45OOUDFHGJKSDBNG" #Sample
)
I dont think this is because I am currently in a different country currently, I think that something else is wrong here.
It doesnt follow through with it, but instead returns a 400 error with that information. Im not sure whats wrong though.
This happens when you copied the callback URI incorrectly. Imagine if this were a client application, and TD detected that the application is trying to send the user to a different URL than the app is configured with. If they send the callback request to that application, it will receive the token and gain full control over your account.
Have you double and triple checked that you're copying the callback URL correctly, protocol name, ports, and trailing slashes and everything? Also, consider using an API library instead of writing your own. You can find documentation about this specific error here.
I had this issue and I solved it using simply using http://127.0.0.1 on the call back URI of the App.
I then used below URL and it worked as expected.
https://auth.tdameritrade.com/auth?response_type=code&redirect_uri=http%3A%2F%2F127.0.0.1&client_id={MyConsumerKey}%40AMER.OAUTHAP
Just in case anyone is still having this problem, make sure the callback URI is spelled EXACTLY the same as you specified when creating the app. I was having this problem because I set the callback on the TD developer website to "https://localhost/" and used "https://localhost" in the URL instead (missing the slash at the end). As soon as I added the slash at the end, it worked.
I found out that the issue is caused by the way the callback URL is set. It have to be exactly the same as the callback URL you have typed in at the apps details on the TD developer API page. I tried several permutations and indeed to get the authorization to work both have to be the same. eg. https or http.. end with '/' or does not, it matters. There is also no need to URL encode it.
I'm trying to setup a facebook share on https://donate.mozilla.org/en-US/thunderbird/share/
The og:url points to just /thunderbird which is the url I would want shared. Best I can tell the og tags are all there.
When I try to update the data on https://developers.facebook.com/tools/debug/og/object/
When I fetch new scrape information I get one of two errors. Initially, it'll take a long time then respond with a Curl Error : OPERATION_TIMEOUTED Operation timed out after 10000 milliseconds with {some number less than 10000} bytes received then subsequent fetch attempts respond with Curl Error : PARTIAL_FILE transfer closed with 17071 bytes remaining to read
We're using AWS Cloudfront and nodejs with hapijs
It responds with a 206 partial content, which, should be fine. The og tags are all in the beginning of the file.
I found this: docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RangeGETs.html
There it says a range request is used to get the file in chunks, not to get just the part of the file and give up. So maybe that's causing unexpected behavior. Maybe cloudfront is sending it back in chunks, and facebook stops listening after the first response? I dunno. Just trying to find a theory that fits the facts.
We already have a working share for donate.mozilla.org/en-US/share/ but that might be old data from when we were not using hapijs and instead using expressjs which I don't think was supporting range requests and would instead return a 200.
I'm mostly a front end dev, so a lot of this is out of my comfort zone but I have already learned a lot :)
Edit: I also want to point out we use Heroku for hosting, and if I setup a test with just heroku and without cloudfront: donate.mofostaging.net/en-US/thunderbird/ it fetches the tags successfully. So I suspect it's a bug when facebook and hapijs interact with cloudfront.
At random (1 out of 100 maybe) the login page to a web application seems to not load any resources, including the CSS. When I was finally able to recreate this issue with network traffic monitored I found some very strange behavior. First, the html page contents get loaded after each resource fetch (see pic 1). Second, all the resource fetches have completely empty response bodies (not shown). Third when I click submit, the normal POST action by j_security_check gets run, but it doesn't seem to do anything and one of the javascript files that is supposed to be fetched and run at the beginning of the page load attemps to be saved to the computer instead. The javascript file is fetched near the bottom, called autocomplete.js.jsf. The contents of autocomplete.js.jsf is a simple framebuster security check:
/**
* Prevent FrameBuster attack
*/
if (window.top.location !== window.location) {
window.top.location.href = document.location.href;
}
Below is an attached picture of the login page and the network traffic. Sorry for all the black, but I am basically a contractor and want to avoid any clues of the client if I can.
Below is what the login page is supposed to look like, with normal web traffic.
Project Info:
I am working on Icefaces v3.3 running on a weblogic v12 server.
I have no idea why this is happening. If anybody could shed some light on why the network traffic looks the way it does, and why it affects the page the way it does I would be very grateful.
In the last couple of days it appears some malicious code is being executed on my coldfusion server. I've found this type of entry in the coldfusion-out.log file
08/20 08:47:02 Information [jrpp-6006] - Starting HTTP request {URL='http://32435898:80/c4/b.txt', method='get'}
I'm trying to track down the source of these HTTP requests but don't know where to look. I've searched all the code for this text and have found nothing, so I suspect it's being injected somewhere. Are there other log files or ways to determine what cf scripts are executing this http request?