Swift has "stringly-typed" enumerations (enumerations with backing "raw values" of string type), but it does not treat the enumerations as equal to the strings. Explicit conversion is required.
I don't think I'd consider it stringly-typed then. To me, stringly-typed means the type system treats strings and non-strings as convertible to each other implicitly. Strings backing enums seems more like an implementation detail and not a type system feature.
I see what you're saying, but it's not 100% an implementation detail. The raw values are accessible through the `rawValue` property, which can be useful for serialization, for example. (That could of course be abused to create bugs like the one here.)
The reason I say Swift "has" stringly-typed enums is that Objective-C has them (typedefs of NSString where the values are actually strings, and are of course implicitly convertible), and Swift imports them as enums with string-typed raw values.
Anyway, I mostly just meant to suggest that this particular iCloud bug is probably not Swift-related.
The javascript matches are "TypeError" not "Type error", and the more important part of those are "...of null" or "...of undefined". They refer to this:
var foo = null;
foo.lastName = "anything"; // TypeError, cannot set property "lastName" of null
And because they are dangerous in yaml, the format in itself is dangerous to use. That's why any sane person should seriously consider whether using the format makes sense.
I am convinced that TOML is the _only_ reasonable configuration format, but very few seem to be swayed.
JSON and YAML are really not made for humans. Configuration must always be a hash. Configuration must allow for expository organization of the content to help humans understand what they are editing (comments, whitespace, section headings are very helpful). Parsing configuration should not result in unexpected code execution.
TOML satisfies those criteria.
I would love to see widespread adoption, but people still seem convinced that storing configuration in JSON is human friendly.
It's just that it's badly made for humans, in that it tries to be too helpful, leading to the various footguns scattered around the format.
TOML can be a bit verbose, especially if you have a case where your keys are more like sentences than they are like symbols. But there are no surprises, and it's quite pleasant to write by hand. I agree that it should be the first choice.
A format that allows references to other sections is not a configuration language that is usable by humans.
I understand the people who created it thought it would be usable by humans, but clearly it is too complicated for anyone to be able to understand a YAML file that is bigger than a dozen or so lines.
I don't mean this in a "if you just swap the parser" way. I mean that in the "if you provide JSON to a program that expects YAML, it will parse it". JSON is a subset of YAML
So not only do you have a way of not using YAML, you can also force this decision onto most third-party services as well, and no-one will know the difference.
YAML sounded like a really great idea to me, until I started actually reading about it. It's a literal minefield.
Some parsers intentionally support subsets of the spec for this reason, and there's multiple specs (like 1.2 which dropped support for things like 'no' to mean false), but that also just means you need to be 100% certain your parser is set up correctly. It's just not worth the extra headache to me.
Yep. I like that you can map the text to programmatic types using the tag system, and anchors are wonderful if not a bit clumsy, but the rest of the standard leaving 10 ways to do 1 thing is just too messy for me.
And there, it is handled by a clear and dedicated layer: ActiveModel::Type::Boolean.new.cast(value)
The only thing you can complain about is that Rails loves implicit magic, which will call this layer for you. Without you needing to set it up, or call it yourself. Many people love this about Rails. (I prefer explicitness over magic.)
Explicit, for me, means that I determine in the model the `published_at` is a DateTime. Not merely in the DB, and never magically derived from the name (_at=datetime, _on=date). But explicitely defined. E.g. `attribute(:published_at, DateTime, default: ->{DateTime.now})`
Rails does not do this entirely "magic", though: it derives it from the database.
And true: you can follow the logic along: the magic can be researched easily. But still: I really prefer a system in which I write all that boilerplace (my IDE/vim can do this for me really well) instead of relying on convention, heuristics and magic.
All inputs in PHP start as strings because you can't tell for certain if a form input was supposed to be 1 or "1", so the language opts to not convert until you trigger it somehow. Combined with PDO for parametrized database queries, if this is PHP this error still should not happen.
Not for technical reasons, someone I knew had the last name Nieffenegger (pronounced "NEF-en-jur") and got banned from Playstation as well as a few other services quite frequently.
My first name is Jaanus, when I moved to Australia and looked for a job one of the major job search sites would stop during signup with a message: ‘your name may contain a profanity’.
It literally means nothing. "May"? contain. It either contains or not. Why is that a problem? Even better it stating it as a statement, like "yes, your name may contain a profanity" (but you don't like it?)
Also, I had two of my friends on facebook who could not use their actual first name of Peep. Like for years they had to use Pepe or Pep. For facebook it was too daring I guess.
It looks like this is just a JavaScript issue; i.e. "true = 'some-value';". I'd be surprised if this was an SQL injection issue, or even XSS since only the user themselves can set their name.
Visual gimmicks like "" (an apple character to designate Apple) are not in keeping with the text-based nature of this site, and "bois" is presumably short for "fanboys" which is flamebaity. These are markers of low-quality discussion which is a different band of the spectrum from what we want on HN.
> "If you're reading this, you've been in a coma for almost 20 years now. We're trying a new technique. We don't know where this message will end up in your dream, but we hope it works. Please wake up, we miss you.",
Why is this piece of string considered naughty? Can't possibly harm any softwares. Might be harmful to wetwares though.
There was a bug (maybe still is) in airbnb where setting your name to include a certain character would brick your login to the web app because it broke header parsing. Reported it but was deemed 'non critical'..
Edit, just looked up the mail
- It was an 'equals' sign
- the reply was:
" It sounds like you cannot cause someone else's account to be in this state, only your own account. Is this correct? How would you get someone else to change their account name so that it includes an equals sign?
It appears that there's no way to cause another user's account to get into this state, and in this case, I do not see a security implication here. "
The name is just a string, right? If some character in the string is causing havoc, maybe there is something funky going on. This is just one symptom coming up at the surface. It might require a bit of extra investigation to see what is really the underlying problem and if that might cause more and different symptoms elsewhere.
This is a key issue I see with bugbounty programs.
They tend to react with "either you can show us that this is a real danger or we'll ignore it".
It seems pretty clear that this bug shows something is terribly wrong and probably dangerous. But the reporter might have limits in analyzing the bug, while the company could easily figure out what's going on and fix it.
> They tend to react with "either you can show us that this is a real danger or we'll ignore it".
This is a bit of a Catch-22 situation, as I get the feeling that proving the danger would often involve doing things that bounty programs specifically forbid, such as "Moving beyond “proof of concept” repro steps"[0]. That may be part of the reason why Microsoft got away with such a stingy response to the RCE vulnerability found in Teams by Oskars Vegeris.[1]
I fault Agile for this and not big bounty implementations. Getting points to address a big because a random internet source pointed it out to us is difficult. There is likely a long backlog of bugs already.
When foreign names are written in Japanese there are a couple of ways of handling puncutation, and sometimes an equals sign is used. I hadn't actually thought about why it was used, but it seems an interpunct (・) is used where a space would be and equals can be used for an internal hyphen, or for words that are separated by a space but part of the same unit (de Niro).
You only need to run into one to make someone's life a PITA. Treat names as free strings, because there are a lot of names that do not conform to any notion of western normality.
> how many names do you run into with equal signs in them?
That's not the issue ... I have not personally tried this or examined it, it looks like you can change the state of the header parser by including interesting characters in your name. I am not sure if this is server-side or client-side. If the problem is server side, there is a chance you could tweak the strings to get interesting results. But trying to prove that this is a serious problem without explicit authorization will likely have adverse consequences for anyone who does, so only people who are already doing shady stuff explore it.
Did you submit it as a bug or a security issue? There are indeed no security risk here, but usability wise, your account being bricked is a pretty serious issue.
My guess is that bug bounty programs refers only to security issues (even if the name suggests otherwise), and unfortunately the team triaging it is probably only focused on handling security teams. Actually sometimes triaging is handled by a different company entirely. In general, very few companies have a solid way to reporting normal everyday non-security bugs, even if they are usage breaking.
I'm curious: if Apple decides not to fix this bug, does Ms. True have any recourse? It seems that in America businesses have the right to refuse service at their pleasure, except for specific forms of discrimination which are explicitly banned. Could Apple, legally, decide that fixing the bug would cost more than they expect to make from her as a customers, and simply reject her business?
Hardly unique to the US. Not sure why they couldn't. It's not discriminating based on a protected class. They would need to stop billing her and refund any moneys for services not delivered. In practice, I assume there is some way to change a name on an account--although I'm told this is often harder than is seems it would be even within a company.
In some countries, the rule is that if you make a public offer (e.g. advertise a price for a product or service), then you must accept all customers. I have no idea how common each system is, though.
Since I’m using a password manager, I’m generating >24 digit passwords, because I’ll never have to type them. You would be surprised how many websites cut everything after 24/32 digits during registration without notice, but suddenly allow more digits in the login form, leading to login issues.
Big props here to Amazon Prime Video for allowing you to open an Amazon app you've already logged into on a device with a camera and scan a QR code on your television to log in, rather than requiring you to type a password using arrow keys to select from a virtual keyboard.
If you have an iPhone, you can use the Apple TV remote on the phone which will show a text input you can type on (on any form text input). This has the added bonus of being able to access your keychain for automatic password filling
I have enabled the tv remote on control center - I’m not sure if it’s there by default. You should be able to toggle it in settings
It’s for these situations that I tend to use pass phrases rather than long random strings of different special characters. Much easier to type 4 or 5 words
This is infuriating. Then you need to go through a password reset to be able to recover the account and some websites don't even bother to tell you how many characters you're allowed to enter in the password field, leading to a whack-a-mole type of situation where you reset password -> check with a lower number of characters -> issues -> reset again and rinse and repeat.
Is there even a point in using passwords that long? It sounds like overkill to me. Assuming your attacker had the computing power of the bitcoin network (ie. attempts per second = hashes per second), then a 16 character alphanumeric password would take more than 800,000 years to crack.
If you are using a password manager, then a (good) longer password is basically extra safety for literally zero extra price, so why not? What does it matter if you are copypasting , or letting the password manager autofill, twelve characters or fifty?
But that's a self-defeating attitude. If you are going to defensively assume that websites are broken in this way, the only logical conclusion is to limit your generated passwords to something ridiculously conservative, like six characters.
In my opinion, it is more reasonable to assume that most websites will behave correctly with even longer passwords, and solve the odd misbehaving ones on a case by case basis.
That's something each of us has to determine for themselves.
I haven't yet, in my many years of "being on the web" encountered a single website with the truncated password problem described above, so for me, it's a weird statistical anomaly to be ignored.
If you have been burned repeatedly by some such websites, you will have a different outlook, and will generate your own passwords accordingly.
Because sometimes you do need to type it. I'm reminded of signing into a Kindle e-reader with shared (family) account and a long randomly-generated password with lots of symbols (I could not change the password). The Kindle has a terrible keyboard and obscures the password input, so what could have taken ten seconds took ten minutes and many attempts.
I use “correct horse battery staple”-style[1] passphrases now because they're still long and secure, but also memorable, so I don't have to enter passwords character-by-character, and I've memorized all of my most-used accounts now and don't need to look them up. 1Password can even generate these types of passwords automatically.
The only annoying bit is when services have arbitrary restrictions like “no spaces”, or “mix of capitals, lower-case, numbers, and symbols”. In those cases I use hyphens instead of spaces, or stick “A1!” on the end.
Fair enough, although as someone who uses a 60 character long home wifi password - and have had to type it out manually more than once in the past - I think it's still worth it, because such cases are rare. :)
One point to longer passwords is passphrases. Passphrases are easier to remember than complicated passwords, and often longer. I can remember the 37 character passphrase “This passw0rd is far too long for me.” much more easily than the 20 character “W64$hmIbAZ7:-IirN57p”
Irrelevant. In a "passphrase", the "symbols" are entire words, instead of single-byte ASCII characters. So "ResearchWannabeProbablyMagmaDeltaCondoneWannabeImpurityScrabbleAbidep" consists of 10 symbols chosen from a list of 7776 symbols. As opposed to "!Z['$-t]8:" which is 10 characters from a list of only 96. Since the entropy of a password (and thus resistance to brute-froce and dictionary attacks) is $log_{2}(Symbols_in_list^{Length_of_password_in_symbols})$, the passphrase has 129 bits of entropy and the password only has 65 bits.
There's no concern about dictionary attacks, since there are too many "words" of multiple "symbols". The symbols just happen to be composed of sequences of ASCII characters, instead of single characters. The analog for regular passwords would be a dictionary consisting only of single letters/numbers/symbols.
> You would be surprised how many websites cut everything after 24/32 digits during registration without notice, but suddenly allow more digits in the login form, leading to login issues.
The input type="password" element allows for passing information to browsers / password managers what the limitations:
I always baffles me when I encounter a service that uses a different validator for sign up than sign in. Firstly, why write this twice. Secondly, it can cause so many headaches.
the one I run into a lot is a + in an email address.
I like to use them on sites I think will likely sell my email address so I'll do something like "my.normal.email+websitename@gmail.com"
I rarely have trouble signing up with this email address, nor verifying it, but then you go to login and splat.
but not properly escaping the lastname of "true" just seems way to basic for a service as large as icloud.
The "+ is not valid character in email" is damn annoying indeed. Too many websites do this dumb "validation".
Re: validating login/signup, I never had an issue immediately. However in practice it happens often when there's one validator but it changes over time during a big rewrite. So you sign up, all works, rewrite lands, can't log in anymore.
Ace Hardware accepts a plus in the email, but then wasn't sending me a confirmation for my pickup order. When I contacted support, I was told my email on file was FOO%2Bace@gmail.com.
I have them all merge into 1, but my mail software can still filter / whatever else based on the To field. Also if someone sells my email address I can just prevent that one from merging and send it into a black hole.
Just wondering, is there a source listing good practices when it comes to implementing how one should sanitize real-world, subjective fields like human names, gender, race etc.? And other gotchas while implementing similar things?
> sanitize real-world, subjective fields like human names, gender, race etc.?
The simple answer is _not to_. Use something you can stuff a bunch of arbitrary bytes into, that will fit the byte encoding that the system is currently using.
Don't sanitise it. Have no expectations about what it can contain. Have a length, have some bytes, and don't ever dare to try and look inside it.
When dealing with anything near banking and human life and anything regulated really, I strongly suggest heavily sanitizing all of inputs. No control characters, no invalid utf-8, no weird whitespace and white list characters you want to allow. Actual list is domain-specific, of course. Limiting input field to reasonable 20 characters will help defence in depth too.
And that's how you end up with a bank unable to handle the existence of certain people because their legal names exceed character limits, contain unexpected characters, or surprise the programmer in other ways. The legal name must be an exact representation, and appear identically. Sanitising it will break things.
I'm not sure there really is a way to have universal good practices, since it really depends on what you're using the information for.
For ex - why are you collecting gender? If it's for some kind of medical process, the requirements of that will tell you what you actually need to know. If it's for some kind of dating thing, you can also figure out from that what you really need to know. If you don't actually know what you need it for, then maybe just don't collect it at all, and you have nothing to worry about.
Ditto most other requirements. Do you need a name for a user in order to meet some kind of legal requirement, or do you just want to be able to put "Hello Username" on the page somewhere? Things tend to get sticky when you might have to interact with multiple external systems with different requirements. Maybe you help run people through some kind of legal process in various countries, and country A's system doesn't support people having a middle name, but in country B this is common and necessary and their systems require it.
Nothing as critical (the negative effects were mostly on my company’s side), but I have created problems for a lot of O’Briens, O’Tooles and other people with similar names.
I am a lot more humble about handling people’s names when writing systems these days...
Many, many moons ago, my employer generated an email address for me, first.o'last@example.com. This is technically valid, but yes, problems everywhere. I put in a ticket asking if I could change it, or at least alias it to first.olast@, for obvious reasons. They never replied.
Over the years, I put in a few more tickets for this. Nada.
Over a decade later, they got in touch and asked if they could change my email address. Turns out they never received my pleas. Turns out our ticket system was one of the systems I had issues with.
My last name is Marié and I smile every time I see write MARIE without the accent, maybe one day it will be a thing of the past and people will stop thinking I'm a girl named Marie
173 comments
[ 6.0 ms ] story [ 202 ms ] threadA sibling comment mentions Swift, but I doubt all components of iCloud are written in it.
https://docs.swift.org/swift-book/LanguageGuide/Enumerations...
The reason I say Swift "has" stringly-typed enums is that Objective-C has them (typedefs of NSString where the values are actually strings, and are of course implicitly convertible), and Swift imports them as enums with string-typed raw values.
Anyway, I mostly just meant to suggest that this particular iCloud bug is probably not Swift-related.
country: xx
... and get to Norway?
I am convinced that TOML is the _only_ reasonable configuration format, but very few seem to be swayed.
JSON and YAML are really not made for humans. Configuration must always be a hash. Configuration must allow for expository organization of the content to help humans understand what they are editing (comments, whitespace, section headings are very helpful). Parsing configuration should not result in unexpected code execution.
TOML satisfies those criteria.
I would love to see widespread adoption, but people still seem convinced that storing configuration in JSON is human friendly.
HCL suffers from only having a reasonable implementation in Go, however.
It's just that it's badly made for humans, in that it tries to be too helpful, leading to the various footguns scattered around the format.
TOML can be a bit verbose, especially if you have a case where your keys are more like sentences than they are like symbols. But there are no surprises, and it's quite pleasant to write by hand. I agree that it should be the first choice.
A format that allows references to other sections is not a configuration language that is usable by humans.
I understand the people who created it thought it would be usable by humans, but clearly it is too complicated for anyone to be able to understand a YAML file that is bigger than a dozen or so lines.
I don't mean this in a "if you just swap the parser" way. I mean that in the "if you provide JSON to a program that expects YAML, it will parse it". JSON is a subset of YAML
So not only do you have a way of not using YAML, you can also force this decision onto most third-party services as well, and no-one will know the difference.
That's false. http://p3rl.org/JSON::XS#JSON-and-YAML
Some parsers intentionally support subsets of the spec for this reason, and there's multiple specs (like 1.2 which dropped support for things like 'no' to mean false), but that also just means you need to be 100% certain your parser is set up correctly. It's just not worth the extra headache to me.
True as you know it can by any of true, “true”, 1, “1”, >0 and most likely more.
And there, it is handled by a clear and dedicated layer: ActiveModel::Type::Boolean.new.cast(value)
The only thing you can complain about is that Rails loves implicit magic, which will call this layer for you. Without you needing to set it up, or call it yourself. Many people love this about Rails. (I prefer explicitness over magic.)
Rails does not do this entirely "magic", though: it derives it from the database.
And true: you can follow the logic along: the magic can be researched easily. But still: I really prefer a system in which I write all that boilerplace (my IDE/vim can do this for me really well) instead of relying on convention, heuristics and magic.
But I’ve used other services (Facebook, for example) that interpret my last name as a boolean and throw errors.
I will show myself out.
https://xkcd.com/327/
It literally means nothing. "May"? contain. It either contains or not. Why is that a problem? Even better it stating it as a statement, like "yes, your name may contain a profanity" (but you don't like it?)
He always said he was very very afraid of being pulled over by police in the States and asked his name.
I wonder if this will be the new anonymity in the future, sort of being like a "john smith" in the past
https://github.com/minimaxir/big-list-of-naughty-strings/blo...
Please don't do that here. The rest of your comment is just fine.
Why is this piece of string considered naughty? Can't possibly harm any softwares. Might be harmful to wetwares though.
I think that’s the point exactly
Edit, just looked up the mail
- It was an 'equals' sign
- the reply was:
" It sounds like you cannot cause someone else's account to be in this state, only your own account. Is this correct? How would you get someone else to change their account name so that it includes an equals sign?
It appears that there's no way to cause another user's account to get into this state, and in this case, I do not see a security implication here. "
They tend to react with "either you can show us that this is a real danger or we'll ignore it".
It seems pretty clear that this bug shows something is terribly wrong and probably dangerous. But the reporter might have limits in analyzing the bug, while the company could easily figure out what's going on and fix it.
This is a bit of a Catch-22 situation, as I get the feeling that proving the danger would often involve doing things that bounty programs specifically forbid, such as "Moving beyond “proof of concept” repro steps"[0]. That may be part of the reason why Microsoft got away with such a stingy response to the RCE vulnerability found in Teams by Oskars Vegeris.[1]
[0] https://www.microsoft.com/en-us/msrc/bounty-online-services?...
[1] https://github.com/oskarsve/ms-teams-rce/blob/main/README.md
https://en.wikipedia.org/wiki/Equals_sign#Personal_names
I regularly encounter services that does not handle it very well
https://crd.ndl.go.jp/reference/modules/d3ndlcrdentry/index....
That's not the issue ... I have not personally tried this or examined it, it looks like you can change the state of the header parser by including interesting characters in your name. I am not sure if this is server-side or client-side. If the problem is server side, there is a chance you could tweak the strings to get interesting results. But trying to prove that this is a serious problem without explicit authorization will likely have adverse consequences for anyone who does, so only people who are already doing shady stuff explore it.
https://support.apple.com/guide/tv/use-siri-dictation-atvb21...
I have enabled the tv remote on control center - I’m not sure if it’s there by default. You should be able to toggle it in settings
In my opinion, it is more reasonable to assume that most websites will behave correctly with even longer passwords, and solve the odd misbehaving ones on a case by case basis.
I haven't yet, in my many years of "being on the web" encountered a single website with the truncated password problem described above, so for me, it's a weird statistical anomaly to be ignored.
If you have been burned repeatedly by some such websites, you will have a different outlook, and will generate your own passwords accordingly.
I use “correct horse battery staple”-style[1] passphrases now because they're still long and secure, but also memorable, so I don't have to enter passwords character-by-character, and I've memorized all of my most-used accounts now and don't need to look them up. 1Password can even generate these types of passwords automatically.
The only annoying bit is when services have arbitrary restrictions like “no spaces”, or “mix of capitals, lower-case, numbers, and symbols”. In those cases I use hyphens instead of spaces, or stick “A1!” on the end.
[1]: https://xkcd.com/936/
There's no concern about dictionary attacks, since there are too many "words" of multiple "symbols". The symbols just happen to be composed of sequences of ASCII characters, instead of single characters. The analog for regular passwords would be a dictionary consisting only of single letters/numbers/symbols.
The input type="password" element allows for passing information to browsers / password managers what the limitations:
* https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
maxlength, minlength, pattern ("A regular expression the value must match in order to be valid").
Until relatively recently, they silently truncated the password that literally protected your bank account to 8 characters.
the one I run into a lot is a + in an email address.
I like to use them on sites I think will likely sell my email address so I'll do something like "my.normal.email+websitename@gmail.com"
I rarely have trouble signing up with this email address, nor verifying it, but then you go to login and splat.
but not properly escaping the lastname of "true" just seems way to basic for a service as large as icloud.
Re: validating login/signup, I never had an issue immediately. However in practice it happens often when there's one validator but it changes over time during a big rewrite. So you sign up, all works, rewrite lands, can't log in anymore.
I love when people argue that it isn't valid even after you contact support.
Generally a sign I don't want to do business with them.
Long story short use a text field that takes UTF-8.
The simple answer is _not to_. Use something you can stuff a bunch of arbitrary bytes into, that will fit the byte encoding that the system is currently using.
Don't sanitise it. Have no expectations about what it can contain. Have a length, have some bytes, and don't ever dare to try and look inside it.
When dealing with anything near banking and human life and anything regulated really, I strongly suggest heavily sanitizing all of inputs. No control characters, no invalid utf-8, no weird whitespace and white list characters you want to allow. Actual list is domain-specific, of course. Limiting input field to reasonable 20 characters will help defence in depth too.
For ex - why are you collecting gender? If it's for some kind of medical process, the requirements of that will tell you what you actually need to know. If it's for some kind of dating thing, you can also figure out from that what you really need to know. If you don't actually know what you need it for, then maybe just don't collect it at all, and you have nothing to worry about.
Ditto most other requirements. Do you need a name for a user in order to meet some kind of legal requirement, or do you just want to be able to put "Hello Username" on the page somewhere? Things tend to get sticky when you might have to interact with multiple external systems with different requirements. Maybe you help run people through some kind of legal process in various countries, and country A's system doesn't support people having a middle name, but in country B this is common and necessary and their systems require it.
I am a lot more humble about handling people’s names when writing systems these days...
Many, many moons ago, my employer generated an email address for me, first.o'last@example.com. This is technically valid, but yes, problems everywhere. I put in a ticket asking if I could change it, or at least alias it to first.olast@, for obvious reasons. They never replied.
Over the years, I put in a few more tickets for this. Nada.
Over a decade later, they got in touch and asked if they could change my email address. Turns out they never received my pleas. Turns out our ticket system was one of the systems I had issues with.