Thomas Musyoka Notes: Key Problem Factors in Web Security
Thomas Musyoka Notes: Key Problem Factors in Web Security
2. Custom Development
3. Deceptive Simplicity :But there is a huge difference between producing code that is functional and
code that is secure.
4. Rapidly Evolving Threat Profile
5. Resource and Time Constraints
6. Overextended Technologies
7. Increasing Demands on Functionality
SELECT/*foo*/username,password/*foo*/FROM/*foo*/users
<img%09onerror=alert(1) src=a>
%00<script>alert(1)</script>
<scr<script>ipt>
....\/
Attacks that exploit the handling of NULL bytes arise in many areas
of web application security. In contexts where a NULL byte acts as a string
delimiter, it can be used to terminate a fi lename or a query to some back-
end component. In contexts where NULL bytes are tolerated and ignored
(for example, within HTML in some browsers), arbitrary NULL bytes can be
inserted within blocked expressions to defeat some blacklist-based fi lters.
Attacks of this kind are discussed in detail in later chapters.
HTTP
THOMAS MUSYOKA NOTES
Status Codes
Each HTTP response message must contain a status code in its fi rst line, indi-
cating the result of the request. The status codes fall into fi ve groups, according
to the code’s fi rst digit:
1xx — Informational.
2xx — The request was successful.
3xx — The client is redirected to a different resource.
4xx — The request contains an error of some kind.
5xx — The server encountered an error fulfi lling the request.
There are numerous specifi c status codes, many of which are used only in
specialized circumstances. Here are the status codes you are most likely to
encounter when attacking a web application, along with the usual reason phrase
associated with them:
200 OK indicates that the request was successful and that the response
body contains the result of the request.
304 Not Modified instructs the browser to use its cached copy of the
requested resource. The server uses the If-Modified-Since and If-None-
Match request headers to determine whether the client has the latest version
of the resource.
400 Bad Request indicates that the client submitted an invalid HTTP request.
You will probably encounter this when you have modifi ed a request in
certain invalid ways, such as by placing a space character into the URL.
404 Not Found indicates that the requested resource does not exist.
n 405 Method Not Allowed indicates that the method used in the request is
not supported for the specifi ed URL. For example, you may receive this
status code if you attempt to use the PUT method where it is not supported.
THOMAS MUSYOKA NOTES
413 Request Entity Too Large — If you are probing for buffer overfl ow
vulnerabilities in native code, and therefore are submitting long strings
of data, this indicates that the body of your request is too large for the
server to handle.
414 Request URI Too Long is similar to the 413 response. It indicates that
the URL used in the request is too large for the server to handle.