Security notes / some attack notes

From Helpful
Jump to: navigation, search
Security related stuff.
website security notes · some attack notes · not-so-formal notes · unsorted

SSL and TLS vulnerabilities

Basic notes on some common attacks/exploits

Denial of Service (DoS) attacks

Man in the Middle

Injection attacks

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Injection attacks means crossing the boundaries between data and non-data.

Exactly how and where that happens varies with what's being attacked. Security implications vary along.

Perhaps the most common cases are those where data and code are mixed, and we can insert something more-or-less verbatim, or via a delimiting step, or even via a parsing/decoding step (...which can be the cleanest, except the edge cases of such translation are nontrivial to see offhand, so it's easy to have a bug).

Consider the ability to insert commands into an SQL statement, commands into Javascript, and Javascript at all into a HTML document (see XSS).

Those last three are probably the best known cases of injection attacks - probably because databases and javascript are so pervasive on the web, meaning it's easier to find exploitable cases.

In theory, any code that builds commands may be injection-sensitive (and might also be the best point to fix this, depending).

Consider LDAP, XPath, any languages' syntax parsing, system calls, interpreted language's code parsing (not just eval()), ability to create subprocesses, and more.

A note on input sanitation

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

SQL injection

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

See also:

LDAP injection

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Similar to SQL injection, since use of LDAP is mostly just a database protocol.

Exploits are a little less likely to be able to be corrupt anything than in SQL, because LDAP has a more API-like interface; different operations are different protocol functions, so it takes particularly bad coding to make exploits as effective as e.g. SQL or XSS exploits.

See also:

Web exploits

Cross Site Scripting (XSS)

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

XSS refers to any insertion of unauthorized/malicious code into pages viewed by others. Often because of exploiting a site's lack of proper input sanitation, and sometimes because of abused trust.

Since XSS refers to code that is executed as trusted code, it can do everything scripting can do, including CSRF, cookie/session stealing, drive-by downloads, and exploit other sorts of trust.

Content meant to do XSS exploits may be

  • stored on the web page (blog comment, forum message/info, IMG trick, etc.),


  • be part of some more immediate processing:
    • consider email containing a link containing form values, that users click and produces a webpage with the given insertion.
    • Exploiting server applications that do not handle form input cleanly; see e.g. HTTP_response_splitting
    • ...or handle session identifiers badly, see e.g. Session fixation

XSS is not very easily filtered when you allow any HTML input (and may be executed in other ways), since it may exploit a lot of different browser parser expoits and can sit in things as simple as links and images.

(As a side note, because some people suggest this for no apparent reason: SSL does not help; it provides encrypted transport between endpoints, and what (XSS) scripting decides to do at those endpoints is unrelated and beyond its control.)

See also:

CSRF: Cross Site Request Forgery

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Known as CSRF (also pronounced 'sea surf'), XSRF, session riding, sidejacking, Cross Site Reference Forgery, one click attack, and probably others.

CSRF is essentially a confused deputy attack.

It makes a user request a page with impliations that the user doesn't know about or want, typically to trigger some operation.

There is often no way for an application to tell that the user was tricked into this particular request, meaning there is very little that it can do.

Such requests can come from links placed on an authentic enough looking page, though need not be links at all. It could be done with an IMG/IFRAME with the URL you wish to exploit and, say, placing that in a forum, RSS feed, or whatnot. It could also be done with XmlHttpRequests (though often only where those are allowed across domains(verify)).

It exploits

  • applications assuming that any interaction comes from a user's browser comes from the user (basically implicit trust by assumption)
  • application features that can be used without needing further interaction - any case where requesting an URL means the application immediately takes action (e.g. 'add post' URL with spam as content, changing a registered email/home address or password, log out, purchase something, etc.)

It does not:

  • give any information to the exploiter (because the only interaction is between the real user and the app they're referred to)

In practice the implicit trust often comes from the 'you are logged in' persistent authentication cookie, and the fact that the application uses nothing else.

Users cannot do much about this (except doing only one thing at a time and always logging out), because it is the application's assumptions that are the problem.

Note that that cookie's value is irrelevant, it doesn't need to be viewed or stolen. SSL doesn't help, nor is it a problem in the tools being used (cookies, query string).

On risk:

Many sites/apps allow such requests in some shape or form. Including some very popular sites.

An exploits does have to be targeted at a specific site, and the exploiting links (or other request causers) need to be placed somewhere that catches enough people to make it worthwhile for the exploiter. The exploit itself needs to have some value for the same reason.

In risk estimation there's some basic math - the amount of the requests that can be expected, the size of the site being targeted, the value of the thing you can get from the exploit. Most sites are relatively safe for the same reason most people are safe from burglars - there are targets than you that are more worthwhile.

But that still doesn't mean you won't ever get burgled. And such a risk estimation will change when your site changes its features, or even just in popularity.

The fact that the basic alleviations are simple enough means it's just very sensible to fix Some web frameworks make make it less work to apply basic protection, but it's not too hard to do yourself. Just a bit of bother per interactive page.


  • Require more interaction
    • For example, when changing any account details, or when doing anything involving money, ask for the current password.
    • Log users out after a few minutes of inaction. Bank sites do this for a reason. Works only if you do one thing at a time, but can't hurt.
    • Effective but bothersome for users
  • Use a shared secret or one-use tokens
    • The basic idea: since actions ought to originate from the app itself you can generate the pages they originate from with a secret, and check whether action submits contain that same value. An attacker cannot generate the URL with a secret unknown to them, so this is fairly strong verification that the request originated from the app itself, and not from some malicious link. (although with XSS you may have problems). Session keys

Neither of these is in itself enough to fend off targeted and properly set up XSS exploits (e.g. fetching the form for the random number), but it does block most of the simpler exploits.

See also:

HTTP Headers

There is no guarantee that any headers are correct in HTTP, since any program can generate requests and their headers.

This is generally not a problem as many UAs (e.g. browsers) do not provide much control of it to users, scripting or such. Most are handled by the UA itself.

Referer spoofing

The insertion of incorrect information into the Referer header. Reasons to do so include:

  • obfuscating the real source of a visit (e.g. using botnets to exploit other services without this being detectable via referrer staticstics)
  • get around hotlinking protection, or getting to areas of sites that allow access based on referrers (e.g. on cooperating paysites).

Ways to do referrer spoofing include:

  • Browser add-ons (there are add-ons for FF, IE and others)
  • Browser plugins (Flash 7 and 8 could build arbitrary HTTP requests)
  • Any self-programmed (non-browser) utility

Browsers create HTTP requests themselves and generally do not allow referrer spoofing via scripting, or in any other way. Ideally, this means XSS cannot lead to referer spoofing; a computer has to be a zombie or include malware to be abused this way.

The mild problem case is XmlHttpRequest. It allows one to add headers, which should not an generally does not include Referer, but some browsers / implementations of XmlHttpRequest are exploitable. The amount of explotable browsers should be fairly low, but it does mean that Referer is not a strictly reliable header.

Referrer spam

Since applications can be made to send in arbitrary URLs in a (non-user-)HTTP request, this is sometimes done seemingly purely so that they end up in your web server's logs.

Usually this has litle or no effect -- the point seems to be that if you have public statistics/summaries/access logs, your site will effectively have a link to the URL that was inserted.

Response splitting

See also

Some more terms to know

On cross-site access