Hot answers tagged

116

This sounds a lot like Fencepost Security. Imagine you're running a facility that has chain-link fencing around it that is 500 feet high. How much would the security improve by making that fencing 3,000 feet high? None - because anyone trying to get in isn't going to climb the 500 feet; they're going to dig underneath, cut a hole, etc. Likewise, you've ...


78

This is a good idea from a security perspective. A password containing unicode characters would be harder to brute-force than a password containing ASCII characters of the same length. This holds up even if you compare byte-length instead of character length, because Unicode uses the most significant bit whereas ASCII does not. However, I think it wouldn't ...


27

First, URL encoding also know as percent-encoding is simple scheme where in the URL %xx represents a byte (a number from 0-255) where each x is a hex digit (base 16: 0-9A-F; note 16*16=256 the number of different bytes). Hence %C0%AF in a URL corresponds to putting the bytes C0 AF into the decoded URL, meaning bytes 192 (1100 0000) and byte 175 (1010 1111), ...


26

First of all "UTF-16 ASCII encoding" is a contradiction, since UTF-16 and ASCII are mutually-exclusive encoding schemes. But presumably he's just referring to using Unicode to bypass filtering mechanisms. The general principle is this: we often think of characters encoded in ASCII -- "A" is the number 65, "z" is the number 122. But that's not the only ...


21

Ignoring the Security by Obscurity argument it is a basic question of entropy. An 8 character unicode password is more secure than an 8 character ASCII password but less secure than a 64 character ASCII password. In general I agree with Sjoerd - these are likely to cause more inconvenience than benefit. On top of this if ever you need to manually enter a ...


18

Browser vendors already try to protect you from homograph attacks by enforcing policies how IDNs (Internationalized Domain Names) should be displayed in the URL bar. Their measures include blacklisting potentially confusable symbols (e.g. ֊, the "Armenian hyphen" U+058A) and displaying URLs with characters from non-latin alphabets as Punycode under certain ...


17

You shouldn't trust the client. Writing Javascript to stop characters being entered does not stop anyone from submitting them to your search. Your search routine should remove characters it doesn't support, and when printing that back out, it should show what it actually accepted, not what was submitted. For general purpose fields in a form, consider ...


14

Your approach - if used correctly - would protect you against two very common attacks: SQL injection and XSS. And escaping/encoding/prepared statements are definitely a must-have and your main line of defense. But as you specifically mention search boxes, your approach might for example not catch SQL wildcard DOS attacks (see here and here), which could be ...


14

The only valid reason I can think of for using Unicode characters in passwords is if the number of characters (not bytes) in a password for a particular site is limited (like this dumb bank that previously had a max of 10 characters), so that it would be easily guessed in a day or two. In this case, you can use Unicode (if the site owners let you) to get ...


10

It is not clear what exactly the slide is referring to. Django's auto-escaping should be fine against HTML-injection in text content and properly-quoted attribute values. There are not other Unicode characters that can evade HTML escaping, but in principle there are byte sequences that could be misinterpreted as being in the wrong Unicode encoding: If the ...


10

This approach could reduce your overall security in certain cases, not improve it. Information Security consists of three attributes: Confidentiality, Integrity, and Availability (the CIA triad). By focusing exclusively on one, you can easily overlook the importance of the others. Confidentiality of passwords is achieved through the principles of entropy:...


9

There are different approaches for homograph attacks. The success depends on the used font. For example in some fonts the small letter l looks very much like the capitalized letter I. And in others they don't. Similarities Use similar characters. They substitute the real character. b ⇔ 6 c ⇔ ( g ⇔ q, 9 C ⇔ ( G ⇔ 6 L ⇔ l, I, 1,...


8

Try looking under the term "Homoglyph" instead of "homograph". For instance, this might be what you wanted: https://codebox.net/pages/homoglyph-detection It contains code and dictionaries.


7

Yes, there are at least three instances where this XSS filter fails. XSS is complex, and blindly replacing characters doesn't solve this problem. The most obvious is if you are writing within a script tag: <script> var x = alert(1); </script> If you are writng an href or iframe src you can use the javascript: URI: <a href=javascript:...


7

Arminius's answer mentions the conditions in which browsers render punycode instead of the actual Unicode glyphs. In my experience, these conditions are not sufficient: for instance, the URL https://аррӏе.com/ (link is safe, but could be a phishing site!) is rendered as punycode by Chrome but not by Firefox: Here is the solution that I personally use. It ...


6

There are cases of SQL Injections leveraging the implicit conversion of Unicode homoglyphs from Unicode character string types (NCHAR, NVARCHAR) to character string types (CHAR, VARCHAR). A character such as ʼ (U+02BC) in NVARCHAR may slip through the escaping routine and get translated to ' (U+0027) in VARCHAR, which may result in an SQL Injection when such ...


5

There is a large number of vulnerabilities and attacks that impact the security of your application. You can start with a list of the most common and critical ones and OWASP Top 10 is the most popular resource containing detailed information and excellent cheat sheets for a quick start. Vulnerabilities come from insecure development practices so here is the ...


5

Assuming you're asking this in the context of Web Development... You can detect appropriate character sets with simple regex validation. However, you may also be falling victim to security theater: input sanitation is not the answer. If you are trying to validate for specific locales, and you don't want to accept any other locales, you can choose specific ...


5

I would add to my spam classification algorithm something that detects multiple encodings in the same word/sentence. E.g., lαѕт having a Latin l, greek/coptic alpha, cyrillic dze, cyrillic te seems very suspicious. A very quick and dirty thing in python could be done using unicodedata. That is >>> unicode_str = u"""мy вυddy'ѕ мoм мαĸeѕ $74/нoυr ...


5

Usually those are UTF8 sequences that resemble other characters, without being them. For example 𝒕𝒉𝒊𝒔 𝒔𝒕𝒓𝒊𝒏𝒈 is not the text "this string", and therefore does not trigger UCE detectors as spam, while you probably read it as "this string", as the sender intended. On the other hand, it is weirdly encoded, so it can happen that it is decoded ...


4

As far as I'm aware, there's no security issue. The "dangerous" characters in HTML (less-than, greater-than, ampersand, single quote, double quote) all have identical byte values under UTF-8 and ISO-8859-1 (and virtually every other encoding you're likely to encounter, with the exceptions of UTF-16, UTF-32, and EBCDIC). As a result, escaping them in one ...


4

If you treat 2 and ² as the same character, you're essentially removing one character from the character set. That isn't really so bad if it increases usability, especially if that encourages longer passwords. Say you take a 8-character password, with a drawn randomly from a set of 2000 characters. That gives log₂(2000⁸) ≈ 88 bits of entropy. If you had a ...


4

Our answer is that for a truly international application, on general input such as people's names, you should accept everything and encode it at display time. Admittedly that (to some extent) passes the problem down to the guy writing the Encode algorithm. However, if you have an input that is a specific thing, such as a vehicle number plate, or a business ...


4

I have no idea if this is the method that Anonymous used, but have a look at http://bugs.mysql.com/bug.php?id=22243 It appears there was a bug in Connector.Net (MySQL's managed .Net driver). From the linked bug report: .net strings are a encoded in UTF-16. Strings are converted to Windows-1252 (SBCS Encoding) to be sent over the network and during ...


4

To answer your two specific examples: Most Western computer systems don't have fonts with complete coverage of CJK characters, and when they do, the appearance isn't always correct. Having a password displayed to you as a series of boxes isn't particularly useful, and worse, some programs will replace those un-displayable characters with substitutes, ...


4

Another thing not mentioned in the other answers: besides its other benefits, a password manager will help you protect against those attacks: your credentials saved for www.google.com will not be filled in automatically on www.googIe.com (the second-to-last character is an uppercase I), hinting to the fact that something is off. You need to copy-and-paste ...


3

In short, the answer is yes to the use of UTF-8 characters in an attack chain. There are a few cases that have crossed my path. What I have read about this method of attack, is that this it is the last step to "drop shell" on an attack chain into a native system. With a quick "Google", this article came up. "Using UTF-8 Encoding to Bypass Validation ...


3

I came to the conclusion from the article that the site was depending more on 'hardening' techniques rather than good sql input filtering/escaping. There is no proof that the kiddie porn sites sql code was not flawed. Bypassing so called hardened PHP filters is often quite trivial. ModSecurity for example can be quite easily bypassed and there are a number ...


3

A problem could be that if you assume that the input is in a different encoding than the browser. (If you don't tell the browser what encoding he should use, most browsers try to guess it). This problem for example has hit Google's 404 page. Here was the fact exploited that IE guesses the encoding of a page as UTF-7 if it finds a valid UTF-7 sequence in the ...


3

Django does the sensible things to reduce exposure to XSS. Django uses unicode and UTF-8 encoding everywhere by default, and sensibly forces unicode encoding before doing substitution on all template variables (done by default) to prevent users inserting arbitrary HTML elements. Django allows developers to change the encoding with the DEFAULT_CHARSET ...


Only top voted, non community-wiki answers of a minimum length are eligible