Security notes / some flaw/exploit notes

From Helpful
Jump to navigation Jump to search
Security related stuff.


Linux - PAM notes · SELinux

Securing services


A little more practical


More techincal waffling

Message signing notes · Hashing notes ·
Auth - identity and auth notes
Encryption - Encryption notes · public key encryption notes · data-at-rest encryption ·pre-boot authentication · encrypted connections

Unsorted - · Anonymization notes · website security notes · integrated security hardware · Glossary · unsorted


SSL and TLS vulnerabilities

Basic notes on some common attacks/exploits

Denial of Service (DoS) attacks

Amplification attacks

Wildly expensive things, and algorithmic complexity attacks, bombs

Man in the Middle

Injection attacks

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

Broadly, 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 with input from users, where data and code become mixed, where that should not be possible.


Consider the ability to

  • insert commands into an SQL statement
  • insert commands into Javascript (e.g. via JSON loads), insert Javascript at all into a HTML document where it wasn't before
(see aldo XSS).


These three are some of the the best known cases of injection attacks - probably because JS and databases are just so commonly used on the web, meaning it's easier to find exploitable cases just by discovering it's being used, and trying some simple stuff.

There are many more thing to which it might apply. Consider LDAP, XPath, any languages' syntax parsing, system calls, interpreted language's code parsing (not just eval()), ability to create subprocesses, and more.


Note that this usually isn't about the software you have having exploitable, as it is about specific application code being careless - often by just dumping a value into the page/command/data without thinking about what characters with special meaning could be in there, like " or ; or --.


Say, if you see a web app that has an input field, try to put in ; alert('problem');. If that page then pops up a message, you know they didn't properly escape things, and there are probably much worse things you can do with that.

SQL injection looks more like '; select * from users --. It's more work because you have to guess about the query you're inserting that into, and there may be a disconnect between feeding that in and seeing the result..

around SQL, there almost always is a way library function (or some syntax-fu that implies it) that amounts to "please do this for me, code by people who have thought about this very hard", and consistently using that is all you need to do to be safe from this particular attack.


What these share is that they mix commands and data in the same syntax, typically with delimiters. Those delimiters are the most obvious way to break things, and the more obvious cases are "code is really just putting whatever the user gave us inside without any checking", but there are subtler cases.



A note on input sanitation

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


Input sanitation is a good idea, but often misunderstood just enough to make it insufficient - and thereby still just as dangerous to trust.


The concept of sanitation can be sound enough, and implementations may be sound, but implementing that yourself takes time, thinking, a lot of testing, and in the case of multiple languages/delimiting systems may actually be easier to mess up than you think.

Remember that it may only take a single mistake.

But more than that, that you are up against equally smart people who collectively have a lot more time on their hands than you to spend on that one particular issue.


Sanitizing comes in two basic flavours:

Blacklisting means you remove specific cases and patterns that you know are bad,
Whitelisting means you only allow specific cases and patterns that you know are good.


The more expressive the context and the more complex the syntax, the harder it is to do both of these.

This is one of the main reasons to avoid rather than fix the problem, e.g. never mix text/code/delimiters in the first place.


Blacklisting is easier for both programmer and users. It is also often wildly insufficient, in that it usually only catches the most obvious cases. It is rare to see blacklisting that is good enough.

Since whitelisting allows very narrow things at a time, it is often easier to prove that each case is safe. It is also more likely to be in the way of real-world use, for pretty much the same reason.


For both, just how complete it is, or even can be, depends on how expressive the thing that's being parsed/executed is.


When delimiting

Never insert a value yourself. Make sure all values are inserted via a function, one that preferably has been proven to avoid all nastiness for the specific backend. (This is harder than you might think, even for just delimiting)


Sanitising data from a user interface is a different thing. In most circumstances, your basic 'clean the string of this and that' is assistance and/or normalization - and not a security feature until you can prove that it is.

Note also even input sanitation as an assisting feature is hard to get right. For example, there are so many cases on the web where correct phone numbers, zip codes, etc. are blocked (and thereby sometimes the ability to use the thing, pay for a thing, etc.) because the coder didn't care to think outside a country's borders

SQL injection

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

See also:

LDAP injection

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, 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:

Replay attacks

When



Web exploits

Cross Site Scripting (XSS)

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


XSS refers to execution environents that are viewed by others (usually web pages) having unauthorized/malicious code inserted into them.


Frequently via exploiting a site's lack of proper input sanitation.

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 exploiting 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.),

and/or

  • 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 and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, 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 centers around a user making a page request, to another site, that results in doing something the user doesn't know about or want.


For example, say you want to add me as a friend on example.com. Doing that in normal use might lead to you visiting:

http://example.com/addfriend?user=me

Which works and is personalized to you because you are logged in (via login cookie).


Say that I know this, and I send you to a page (or send you a HTML email) that contains

<a href="http://example.com/addfriend?user=me">look at cute kittens</a>


If you are still logged into example.com when you click it, all example.com sees is a request from an authenticated user to do the thing.


This is a specific case of the confused deputy attack, because while I, the attacker, have zero ability to see or interact with that site as you, and you reveal zero information to me, I exploit the fact that you are authorized to do a thing that is beneficial to me.

Possibly without you realizing.






See also:

HTTP Headers

Anyone can craft a HTTP request, so there is no guarantee that any headers are correct.


Browsers, on the other hand, handle most headers by itself and do not provide much control of headers to its users, scripting.

As such, this isn't as much of an issue for webpages, it's more a think that servers have to think about.


Referer spoofing, referrer spam

The insertion of incorrect information into the Referer header (a header that tells a server the previous page you were on).


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:

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

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

Privacy issues

IP leak

DNS leak

See also

Some more terms to know

On cross-site access