从用户提供的路径显示文件的安全隐患

Question

Assume some intranet WebAPI endpoint like:

public class AttachmentDto
{
    public String Path { get; set; }
}


public class AttachmentsApiController : ApiController
{
    public void Post(AttachmentDto attachment) 
    {   
        var attachmentsStorage = new AttachmentsStorage();
        attachmentsStorage.Add(attachment.Path);
    }
}

where AttachmentsStorage in one or another way reads the file at attachment.Path (one or another network share) and saves the contents at some more or less publicly available and known place.

That is basically equivalent to simply

public String Post(AttachmentDto attachment) 
{   
    return File.ReadAllText(attachment.Path);
}

That in my opinion evaluates to security vulnerability , even though the system is intranet, because any file on the server that is accessible to the used service account can be technically read.

Am I correct?

---

If it is so, then what can be done to mitigate this issue?

I've considered:

1. Pass the file contents - possible, though not desired for this particular system because of the assumed design and possible size of the files.

2. Prohibit any addresses that are not network shares. Something like:

    private Boolean IsNetworkShareFile(String path) { var uri = new Uri(path); return uri.IsFile && uri.IsUnc && uri.IsAbsoluteUri; }

It seems to work, but it at best prevents only local file access(though some file share can actually point to local) and doesn't restrict access to private shares.

3. Try impersonation/delegation - probably the best solution with authentication mode="Windows" , though it will require changing account settings in Active Directory

Answer 1

This is an A4

What you are describing is known as an Insecure Direct Object Reference and is in the OWASP top 10.

You can guess the mitigations from the title. You can either

1. Secure the references, or
2. Use indirect object references instead

(or both)

Secure the reference

The server should validate Path , ideally against a white list .

Paths can be a little tricky to validate because they can contain escape characters. Be sure to use Path.Combine and MapPath instead of performing any path computation yourself.

Also, since this is a string that is being input into your system, always check for injection .

Use an indirect object reference

Modify the API's interface so the client submits a PathID instead of a Path , and make PathID discoverable via some other service call which lists only those specific files that the client has the right to access. If the system has per-user permissions (ie ACL ), then bind the PathID namespace to the user session, so that one user cannot guess another user's PathIDs.