is there any security issue if I send a path in a QueryString? like if send this request http://localhost/eCTDTreeViewer/Home/Index/?pathOnServer=G:\test\company2

- 123
- 1
- 12
-
Why would you do that? What are you trying to achieve with it? – cassiomolin Jun 20 '16 at 12:39
-
@Haider - Have any of the provided answers, answered your query? If so, could you take the time to select which answer suits your question the most. :-) – Juxhin Jan 19 '17 at 09:50
4 Answers
The risk of exposing a path, given the filesystem is not externally accessible, is negligible.
Especially if the sole purpose of the component you're talking about is to display directories as they exist on the server. What you see in the query string is what you will see in the payload of the response, so it's just fine having the path there in plain text.
Trouble can arise when this "TreeViewer" exposes sensitive files and allows the user to browse to arbitrary locations, enabling them to retrieve passwords stored in files and what not.
Of course it never hurts to add HTTPS, but that only prevents a man in the middle from finding out which directories and files exist on that server and does not offer anny additional security.
HTTPS does not make your improperly secured application secure, you still have to implement authentication and authorization, input sanitation and so on.

- 147,647
- 23
- 218
- 272
Thinking about QueryString security, you should keep in mind (read as "worry") the following moments:
- URLs are stored in web server logs
- URLs are stored in the browser history
- URLs are passed in Referrer headers
You can find more detailed information about this reading How secure are query strings over HTTPS article and Is an HTTPS query string secure? question on SO.
Yes, you open yourself up to Directory Traversal (DT) and Local File Inclusion (LFI) attacks.
The main difference between the two is that DT is read-only in which a user can access any file on your web server provided that they have sufficient privileges. LFI on the other hand would allow you to invoke a file (e.g. a PHP file) on the web server rather than reading it.
If, for example, you have a SQL Injection
vulnerability on your web application, an attacker may deploy a web shell into your system:
SELECT "<?php system($_GET['cmd']); ?>" INTO OUTFILE C:/tmp/shell.php
An attacker could then invoke the file:
http://localhost/eCTDTreeViewer/Home/Index/?pathOnServer=C:/tmp/shell.php?cmd=echo "foo"
This is very brief but it should provide a good idea as to how dangerous it can be.

- 5,068
- 8
- 29
- 55
If you stay in plain HTTP, yes. The request will be sent in plain text over the network. Don't be confused, it will be the same issue with a POST request with your information inside the body of it.
The good way to make it safe is to use HTTPS. Because of the handshake done before the exchange, the full request will be encrypted (with the path as well) to be sent to the endpoint.

- 4,054
- 2
- 31
- 53

- 2,483
- 1
- 14
- 20
-
-
Using HTTPS the querry string is sent encrypted so HTTPS does provide additional security. – zaph Jun 20 '16 at 13:12
-
HTTPS holds no value here, the attacker can still manipulate the `pathOnServer` query and examine the response for vulnerabilities. – Juxhin Jun 20 '16 at 20:05