In one of his recent blog entries, Brian Moon takes a …

There are so many incorrect assumptions, and many incorrect practices when cleansing GET also.

1) Don’t remove characters like %$&^&$, you escape them to their ASCII character codes.
2) GET requests aren’t evil, and providing you’ve got full control of the HTTP request and know what data was passed from where, you can easily ascertain if there are any errors.
3) GET and POST exist for specific reasons. With merging GET requests with POST requests, you are able to use a central way to access elements that are the same, but also you then give precedence to whichever is prepended or appended to the array. You won’t know which came from where, and if the key in GET exists already then it’ll essentially be an intersect; as per php.net/array_merge — “If the input arrays have the same string keys, then the later value for that key will overwrite the previous one.”.

If you want to use POST, then use POST as it was most originally intended in RFC , but essentially derived to the use of forms:

” The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions:”

- Annotation of existing resources;

- Posting a message to a bulletin board, newsgroup, mailing list,
or similar group of articles;

- Providing a block of data, such as the result of submitting a
form, to a data-handling process;

- Extending a database through an append operation.

The GET request is a different method, used for a different purpose and is distinctly required and shouldn’t just be noted as “insecure” due to the fact that people are able to provide simplistic SQL injection or old-school “shell injection” or XSS — all it needs to be fixed is sane code and logical checks on GET requests. Again, as per the HTTP 1.1 definition:

” The semantics of the GET method change to a “conditional GET” if the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the entity be transferred only under the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce unnecessary network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already held by the client.”

Not being offensive, just saying that this isn’t neccesarily a great option or practice you can use to minimise security issues when you’re essentially obfuscating things more than you need to.

No, you are not confused; but most of the rest of the world is. Unfortunately, to many people cannot tell the SEMANTIC difference between a GET and a POST request: I have seen sites developed entirely using POST and an unique URL (this is quite common among java developers), and I have seen sites where GET requests would delete data.