I have a file upload API running in IIS. I am calling it from a WPF Application. I have file names like "Test-12345–Coverage–TestFile-2018Jul23".
If you see this file name, it has got a '-' and a '–'. Eventhough they look alike, they are different. Our clients get these filenames generated through some external system, but when I try to upload these files through my webapi. I am getting a 400 Bad request error. It looks like '–' is treated as an invalid character in the http request making it a bad request. If I change '–' to a '-', it works fine.
Is there a list of restricted characters in http request stream objects? If so I would like to know and share it with my clients. There is a debate of application should handle these characters since windows file system allows naming files with these characters. But if IIS rejects it, I don't know what to do. Please advice.
Stream s = System.IO.File.OpenRead("C:\Desktop\Test**-** NoticeInfo **–** funding- July 26, 2018.pdf");
StreamContent content = new StreamContent(stream, Convert.ToInt32(buffer));
_httpClient.PostAsync("http://myurl/api/v1/UploadDocument", content); //The code breaks here
Notice the '-' in the file name. There are two occurences. First one is a standard Keyboard '-'. The second one is a different hyphen. These file names are generated from another system and we are using it to upload in our system. But for some reason IIS did not like the second –, it treats the whole request as a bad request.
Related
I am running lighthttpd in Linux on an embedded platform.
Now i want to make it possible to transfer a file to the system, with an upload web page containing a file selector and "Upload" button (with HTML tags and ). The selected file is transferred as a POST HTTP request containing multipart/form-data. The file should then simply be stored as a regular file in the file system.
I'm already having a CGI interface, a bash script which receives the request and which passes it to the backend C++ application. And because it is an embedded platform, i would like to avoid using php, python etc. only for this case.
As far as i see, lighttpd is not able to save the received files directly from multipart-encoded request body to pure files, correct?
To decode the body i found 'munpack' tool from the mpack package, which writes the encoded body to files on disk, but is intended for mime encoded emails. Nevertheless i can call it in the CGI bash script, and it works almost like expected, except that it can't handle the terminating boundary id (the boundary id given in 'Content-Type' appended by two dashes), resulting in the last file still containing the final boundary. Update: This munpack behaviour came from a faulty script, but still it doesn't work, munpack produces wrong files when the body contains CRLF line endings; only LF produces the correct result.
Is there any other direct request-to-file-on-disk approach? Or do i really have to filter out the terminating boundary manually in the script, or write a multipart-message parser in my C++ application?
To make the use case clear: A user should be able to upload a firmware file to my system. So he connects to my system with a web browser, receives an upload page where he can select the file and send it with an "Upload" button. This transferred file should then simply be stored on my system. The CGI script for receiving the request does already exist (as well as a C++ backend where i could handle the request, too), the only problem is converting the multipart/form-data encoded file to a plain file on disk.
Now i want to make it possible to transfer a file to the system, through a POST HTTP request. The file should simply be stored as a regular file in the file system.
That sounds more like it should be an HTTP PUT rather than an HTTP POST.
As far as i see, lighttpd is not able to save the received files directly from multipart-encoded request body to pure files, correct?
Do you mean application/x-www-form-urlencoded with the POST?
Why multipart-encoded? Are there multiple files being uploaded?
lighttpd mod_webdav supports PUT. Otherwise, you need your own program to handle the request body, be it a shell script or a compiled program. You can use libfcgi with your C++, or you can look at the C programs that lighttpd uses for testing, which implement FastCGI and SCGI in < 300 lines of C each.
From https://en.wikipedia.org/wiki/Query_string
A web server can handle a Hypertext Transfer Protocol request either
by reading a file from its file system based on the URL path or by
handling the request using logic that is specific to the type of
resource. In cases where special logic is invoked, the query string
will be available to that logic for use in its processing, along with
the path component of the URL.
What does the quote mean by the two methods by which a web server can handle a HTTP request
"by reading a file from its file system based on the URL path"
"by handling the request using logic that is specific to the type of resource"?
Can you give specific examples to explain the two methods?
Is the query string used in both method?
Thanks.
by reading a file from its file system based on the URL path
^ The web site uses a generic mapping mechanism to convert a URL path to a local filesystem path, and then returns the file located at that path. This is common with static files like .css.
by handling the request using logic that is specific to the type of resource"
^ The web site turns control over to a web application, which contains code written by a developer. The code reads the query string and decides what to do. The logic for deciding what to do is completely customizable, and there does not need to be a static file in the local filesystem that matches the URL.
Our application server is receiving a few dozen requests per day with a malformed URL, containing a random .png image reference on the end of the GET.
For example, our URL (with parameters) is supposed to end with this:
&quiz_psetGuid=PSETC0A80101000000234e7960020000
And instead it ends with this when the server receives it:
&quiz_psetGuid=PSETC0A80101000000234e7960020000/cfyxqvn.png
The .png reference is not ours and we didn't put it there. Needless to say it makes it impossible to read the URL parameter.
This problem occurs from multiple user agents.
Any idea where this is coming from?
We've been seeing these requests recently and as they also come from logged in members, it is quite clearly some add-on (likely some malware) installed on various machines. In our case there's no / added before the random string so a valid url sucj as
/hu/stamps/countries
becomes
/hu/stamps/countriesudkatuuajqi.png
I have a ServerResource object that is running within a component. Its purpose is to act in many ways like a basic HTTP server. It uses a Representation to acquire a file and return the file's contents to a browser.
The active function for this application is provided below:
public Representation showPage()
{
Representation rep = null;
if(fileName != null)
{
File path = new File("pages/" + fileName);
rep = new FileRepresentation(path,MediaType.ALL);
}
return(rep);
}
Note that "fileName" is the name of an HTML file (or index.html) which was previously passed in as an attribute. The files that this application serves are all in a subdirectory called "pages" as shown in the code. The idea is that a browser sends an HTTP request for an HTML file, and the server returns that file's contents in the same way that Apache would.
Note also that the restlet application is deployed as a JSE application. I am using Restlet 2.1.
An interesting problem occurs when accessing the application. Sometimes, when the request comes from a Firefox browser, the server simply does not send a response at all. The log output shows the request coming in, but the server sinply does not respond, not even with a 404. The browser waits for a response for a time, then times out.
When using Internet Explorer, sometimes the browser times out due to not receiving a response from the server, but sometimes the server also returns a 304 response. My research into this response indicates that it should not be returned at all -- especially if the HTML files have no- caching tags included.
Is there something in the code that is causing these non- responses??? Is there something missing that is causing the ServerResource object to handle responses so unreliably? Or have I found a bug in Restlet's response mechanisms?
Someone please advise...
I've implemented a PDF generation function in my flex app using alivePDF, and I'm wondering if the process I've used to get the file to the user creates an XSS vulnerability.
This is the process I'm currently using:
Create the PDF in the flex application.
Send the binary PDF file to the server using a POST, along with the filename to deliver it as.
An ASP.NET script on the server checks the filename to make sure it's valid, and then sends it back to the user as an HTTP attachment.
Given that, what steps should I take to prevent XSS?
Are there any other GET or POST parameters other than the filename?
In preventing XSS, there are three main strategies: validation, escaping, and filtering.
Validation: Upon detecting nvalid characters, reject the POST request (and issue an error to the user).
Escaping: Likely not applicable when saving the file, as your OS will have restrictions on valid file names.
Filtering: Automatically strip the POST filename parameter of any invalid characters. This is what I'd recommend for your situation.
Within the ASP.NET script, immediately grab the POST string and remove the following characters:
< > & ' " ? % # ; +
How is this going to be XSS exploitable? You aren't outputting something directly to the user. The filesystem will just reject strange characters, and when putting the file on the output stream, the name nor the content does matter.