Difference between revisions of "Security notes / some attack notes"

From Helpful
Jump to: navigation, search
m (Response splitting)
m (Response splitting)
Line 438: Line 438:
 
In essence a sanitation/injection problem at HTTP level
 
In essence a sanitation/injection problem at HTTP level
  
If server code does not clean up what it puts into e.g. Set-Cookie,
+
If server code does not clean up what it puts into e.g. Set-Cookie, then a value like "\r\nContent-Length:1000\r\n\r\n" followed by 1000 bytes of malicious page - this will ''functionally'' replace the original page.   It hasn't replaced the original content, just made it look to browsers like superfluous data.
then consider setting a cookie value of something like
+
"\r\nContent-Length:1000\r\n\r\n" followed by 1000 bytes of malicious page - this will ''functionally'' replace the original page.  
+
Note that it hasn't replaced the original content, just made it look to browsers like superfluous data.
+
  
 
If possible, this is a powerful tool supporting other attacks.
 
If possible, this is a powerful tool supporting other attacks.
 +
 +
 +
That said, any serious server gets this right, so this is more of an issue of DIY ones.
 +
  
 
-->
 
-->

Revision as of 16:07, 27 June 2022

Security related stuff.

Practical


Theory / unsorted



how to do a login system badly
how to do encryption badly
encrypted connections
data-at-rest encryption


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, 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, 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, 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, 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, or tell me)


XSS is a web based attack, and refers to any insertion of unauthorized/malicious code into pages that are viewed by others.

Often via 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 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, 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

See also

Some more terms to know

On cross-site access