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.
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.
I am working on a legacy Application which has some cross site scripting - reflected issues when we take the input from query string. The issues are being reported by Fortify code scan (WebInspect) tool.
For example:
I have a page called ProgressDisplay.aspx which takes reportPath as a query string parameter.
/ReportViewer/ProgressDisplay.aspx?reportPath=%27%3b%61%6c%65%72%74%28%35%36%36%34%35%29%2f%2f
In the above code reportPath is a query string parameter where the malicious payload is being passed which shows an alert in the response.
Above payload becomes alert(56645) after rendering.
Like this, there are several similar issues are being reported. Is there any centralized approach to fix all the issues at one shot by using any ASP .Net library Or making some changes in the config instead of fixing each issue Or I'll have to fix all the issue one by one?
After the fix, the page shouldn't return the response as 200 when a malicious script is inserted. We have to return a Bad Request in response.
Use below recommendation to avoid Cross site scripting attack in Microsoft.NET Language :
URL Encoding : It prevent malicious script from being injected into a URL.
Not: You can use Microsoft Web Protection Library (WPL) to avoid all xss-Reflected issues.
eg: <a href=<%# Microsoft.Security.Application.Encoder.UrlEncode(TEST.Url) %>>View Details</a>
Enabling a Content Security Policy (CSP)
Validated Input data:Input data should be validated Before execute.
XSS- Microsoft.NET
Encode data on output
When I try to upload a text file with special characters in a post Http request on JMeter, those characters are replaced by "??????".
Is there a way to define UTF-8 encoding to the file name?
Add Debug Sampler to your Test Plan
Configure it as follows:
Add View Results Tree listener to your Test Plan
Run the test
Look for file.encoding property under response data tab
If what you see is different from UTF-8 - you will need to change the setting either by adding the next line to system.properties file
file.encoding=UTF-8
or passing it via -D command-line argument like:
jmeter -Dfile.encoding=UTF-8
Once done JMeter should be able to use/show non-ASCII file names properly
References:
How to get and set default Character encoding or Charset in Java
Apache JMeter Properties Customization Guide
Overriding Properties Via The Command Line
I had the same issue and the above didn't help either. For me what worked was adding a combo of user defined variables and body data.
First create the data you want to send as variables in 'User Defined Variables', referencing these in the POST using $(name_of_var).
Then also make sure you are using 'Body Data' instead of 'Parameters' in your http request e.g...
For some reason this worked for me, I think jmeter doesn't apply encoding to variables by default.
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.
Personally, I try and write secure ASP.NET code. However, I have become quite paranoid about the code I write, as I used to work for a Registrar (high fraud targets). Are there any ASP.NET functions I should look at with extreme scrutiny (other than SQL access - I know enough not to do dynamic SQL).
This is an excellent MSDN article: Security Practices: ASP.NET 2.0 Security Practices at a Glance.
Excerpt:
How to prevent cross site scripting
Validate input and encode output.
Constrain input by validating it for
type, length, format, and range. Use
the HttpUtility.HtmlEncode method to
encode output if it contains input
from the user, such as input from form
fields, query strings, and cookies or
from other sources, such as databases.
Never just echo input back to the user
without validating and/or encoding the
data. The following example shows how
to encode a form field.
Response.Write(HttpUtility.HtmlEncode(Request.Form["name"]));
If you return URL strings that contain
input to the client, use the
HttpUtility.UrlEncode method to encode
these URL strings, as shown here.
Response.Write(HttpUtility.UrlEncode(urlString));
If you have pages that need to accept
a range of HTML elements, such as
through some kind of rich text input
field, you must disable ASP.NET
request validation for the page.
Turn On Custom Errors To Keep Errors Private
<customErrors mode="On" defaultRedirect="YourErrorPage.htm" />
Never trust user input. Never assume client-side validation will prevent bad input data. Always ensure that ValidateRequest="true" and EnableEventValidation="true" in your web.config :
See Request Validation and ASP.NET Security Tutorials.