Securing the pubsub() Function - Continued

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Speaker 1: There's still one attack left, and this one is an out of order attack. That the attacker can cause a message to be delivered before another message, at least to some subscribers. By doing so, he can create confusion in the marketplace. How do you do that?
>> Speaker 2: You did this in school, should it in your messages in the order to be subscribers.

[00:00:31]
>> Speaker 1: Each of the subscribers should get them in the order that subscribed, and they should also each of them should get the messages in the order that they are sent.
>> Speaker 3: And some subscribers subscribe with the number?
>> Speaker 2: No, that would cause an exception to get thrown, and we already ignored those.

[00:00:51]
>> Speaker 3: So we're assuming at this point that we're working on the foreach loop rather than the previous either one, but not to focus on this one.
>> Speaker 1: You like, since we can see that the corrections that we have made up to this point have fixed this new And so much of the push push on.

[00:01:15]
>> Speaker 3: It's very easy pushing their function methods or screw with the order of it, reverse it?
>> Speaker 1: No, you're talking about the first problem we did?
>> Speaker 3: Yeah.
>> Speaker 1: Yeah, and that one was using store, because we could name where it was going to go, and that's when we haven't provided an API for doing that.

[00:01:40]
>> Speaker 3: Gotcha.
>> Speaker 1: And the good thing about this construction is that that's impossible because they, well, it's something that we fix the thing, where they can get access to the subscribers or a through this. There is no way that they can add a property to subscribers except through the subscribe function.

[00:02:06]
>> Speaker 2: Doesn't have access to this anymore, to the-
>> Speaker 1: That's correct.
>> Speaker 4: Are we trying to get the messages out of order or the subscribers out of order?
>> Speaker 1: The message is out of order.
>> Speaker 3: Set time out. Is and that would make, it would change where yours comes in.

[00:02:45]
>> Speaker 1: Yeah, settimeout might be part of the solution but it's not part of the problem.
>> Speaker 2: You know we might wait.
>> Speaker 1: We don't have to wait on the site.
>> Speaker 2: You know and that's because it's synchronous anyways if it works if we just call everything just exactly as in effect.

[00:03:09]
>> Speaker 1: because it is it stops everything ready. So yeah so that that's not part of this you know every time you click every time somebody calls publish a publication is that's the message right?
>> Speaker 2: Is gonna read through the subscribers and call it and then what you're saying is I call it and then you call it after me you're that you're in the bad guy you call it after me because somehow or yours jumper wire infront of mine.

[00:03:49]
>> Speaker 1: Yeah.
>> Speaker 1: That's what we're looking for. But you can't call it until it's finished with mine because it's, the process is long. But that wrong.
>> Speaker 2: Right.
>> Speaker 3: Can I pass in the pubsub object to my function? and then resubscribe myself in the midst of a call.

[00:04:14]
>> Speaker 1: You're close. It's not quite like that but it's that kind of this.
>> Speaker 2: Is this a vulnerability in for huge not because these are just some preachy Right.
>> Speaker 3: So are we essentially creating an infinite loop based on what he said.
>> Speaker 1: We are not looking for an infinite loop because an infinite loop would be a denial of service attack.

[00:04:42]
>> Speaker 3: Okay.
>> Speaker 1: And someone can do an infinite loop without calling our code. They can just sit in their own code into an infinite loop so that that's not something this code can defend against.
>> Speaker 2: And inside of forEach, can you change the value of s?
>> Speaker 1: Yes.

[00:05:03]
>> Speaker 2: So if I publish one object, and then later on, publish another object And that separate object has a function in it that sets aspect to the first object. Is that a nasty thing to do.
>> Speaker 1: Well that's not likely to happen because whatever function you're going to be doing, that will be created outside of the scope and so will not see at.

[00:05:33]
yeah only functions in this scope can see us.
>> Speaker 3: So if I pass it. The pops up to my subscribers function when my function is called I call public Again.
>> Speaker 1: Yes.
>> Speaker 3: And we restart to loop in the beginning again.
>> Speaker 1: Exactly.
>> Speaker 3: And we keep on doing that we'll never get it.

[00:05:56]
>> Speaker 1: Right. So, this is a tacky just describe. So, he subscribes a function Which will publish and this function gets called in the publication loop so he can cut it. He can then cause his own message to get published and delivered to everybody who is after himself in the subscriber list And in doing that, he causes things to go out of order.

[00:06:28]
>> Speaker 4: Leonardo in the chat room beat us again.\
>> Speaker 1: Way to go Leonardo.
>> [LAUGH]
>> Speaker 4: Well Vincent was the first, yeah Vincent beat us last time. This time it was Leonardo.
>> Speaker 1: You need to be telling us that. Before-
>> Speaker 4: I know.
>> Speaker 1: Yeah.
>> Speaker 4: I didn't know it's like-

[00:06:46]
>> Speaker 2: He's a
>> Speaker 4: Yeah.
>> Speaker 1: Okay, so the reason I used the limit function that we wrote yesterday. Because if I don't then I'm just creating a denial of service attack, right. We'll keep calling it over and over again recursively. And a denial of service attack doesn't accomplish the security exploit that we're trying to do, it just impairs a system.

[00:07:08]
>> Speaker 2: A limit's what we wrote yesterday.
>> Speaker 1: Yeah we wrote limit yesterday, so that means when I get called I am going to send one message. And that message will get delivered before everybody else. So how would you fix that?
>> Speaker 2: every time somebody publishes a message. My message will go out it would only ever happen once.

[00:07:36]
>> Speaker 1: Well but I can control it you know this is the simplest way to keep it from getting Getting abusive but obviously we can put a smarter function in there that could change its behavior every time it's called.
>> Speaker 3: You could take off the subscriber and make sure it's not an object right?

[00:07:58]
The subscriber before you push.
>> Speaker 1: No, the subscribers have to be In fact, that's what the tri catch was for, to guarantee that they are functions.
>> Speaker 3: Okay. Can you-
>> Speaker 2: Would you just temporarily changed the value of publish to something else, but it's frozen.
>> Speaker 1: Right we, yeah we fixed that one.

[00:08:23]
>> Speaker 2: I was just trying to think of a way to disable publish inside of this loop. So if you just set, you could, yeah, you put a var at the top of this that says publish off.
>> Speaker 1: Yeah, we could put a boolean up at the top which says, we're in the publication mode, so subscribe or publish is turned off while we're looping.

[00:08:44]
That would certainly work. The way I would approach it is, I would do an asynchronous solution because I like a synchrony. So there's something that's in browsers and in Java and in node called setTimeout. And setTimeout receives a function and causes that function to get executed in the future.

[00:09:06]
And you can give it a time which says no sooner than zero milliseconds from now call this function. But this function happens in a different turn. So it'll get scheduled after all of the current work in the current turn is finished. So this would cause. Everything to get lined up in the timer queue and then if someone wants to subscribe during a publication, their stuff will get added later in the timer queue.

[00:09:35]
So everything stays in order, we're using the timer queue to sort the messages.
>> Speaker 1: Now, so we could do that.
>> Speaker 3: So you move the publication off into a separate queue the one that gets processed independently if whatever goes on here?
>> Speaker 1: Right and it also means I don't need to try catch here now because If it fails it'll fail in that turn.

[00:10:00]
But then the system says, well that turns finish and will go on to the next one. And so everything keeps going. Now it turns out there's one hazard in this because of the design error in the way such a timeout works when you pause such timeout it returns a number And you can pass that number to clear timeout and that'll prevent things from happening.

[00:10:23]
Unfortunately, it is an easily guessable number. And that means if the attacker can guess what the next clear timeout number is going to be. He can prevent messages from being delivered. By cancelling those messages that are in the queue. So we would have to fix that but we'll fix that one another day.