Http put

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request. If the resource could not be created or modified with the Request-URI, an appropriate error response SHOULD be given that reflects the nature of the problem. The recipient of the entity MUST NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and MUST return a 501 (Not Implemented) response in such cases.

If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI,

it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.

A single resource MAY be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which is separate from the URI identifying each particular version. In this case, a PUT request on a general URI might result in several other URIs being defined by the origin server.

HTTP/1.1 does not define how a PUT method affects the state of an origin server.

PUT requests MUST obey the message transmission requirements.

Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request SHOULD be applied to the resource created or modified by the PUT.

HTTP PUT Security

Many web developers are familiar with the GET and POST methods of allowing a user to submit data to a web application. Lesser known is the PUT method, which allows a user to upload files and turn them automatically into new URL's.

Security & HTTP PUT

Many web developers are familiar with the GET and POST methods of allowing a user to submit data to a web application. Lesser known is the PUT method, which allows a user to upload files and turn them automatically into new URL's.

PUT can be dangerous if it is not properly locked down. In the worst case scenario, imagine a website allows anyone to PUT data. An attacker could craft a special php script which would add a new user account to the server with root (admin) access. The attacker then performs an HTTP PUT with this file, and a new URL would be formed. When the attacker navigates to this URL, the PHP file is executed by the web server, and can modify any files the web user on the system has access to, including existing web pages.

Sometimes PUT is a useful part of a web application. The key is making sure only authenticated users have access, and those authenticated users are carefully limited so only trusted users are allowed to perform PUT's. In this way, the PUT users are trusted as if they had an account on the server itself, and were able to upload or modify files via other methods, such as FTP.

How Does this Impact my Security?

If PUT requests are accepted by non-trusted accounts (generally non-administrator) or the web browsing public, then this will allow an attacker to take complete control of your site and possibly the entire web server as well.

Implementing HTTP PUT Security

If your website does not require PUT functionality, then it is recommended to switch to another secure protocol which uses specific user logins, such as SFTP. If PUT is needed for the application, be sure to lock down all users. A double authentication is the best method of ensuring this type of functionality - first with a web user login, and also with HTTP authentication.