TypeScript, Security, and Type Juggling with Ariel Shulman & Liran Tal - JSJ 679 - JavaScript Jabber

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:05):
Hello everybody, and welcome to another exciting episode of JavaScript Jabber.
Today on our panel, we've got a j O'Neil how aj.

Speaker 2 (00:15):
Yo yo yo, coming at you live from the Shed.

Speaker 1 (00:19):
The Purple Room, the Purple Room, and.

Speaker 3 (00:22):
Steve Edwards yo coming at you from a how's always
cool and cloudy Portland this time of year?

Speaker 4 (00:29):
Wow?

Speaker 1 (00:30):
Here in tel Aviv it's well, it's effectively summer really,
So we've got two great guests with us this week.
We've got Ariel Schulmann and we've got Liran Tal Say
hi to our listeners please.

Speaker 5 (00:46):
Hey, how's everybody going live from Tel Aviv? Which is
again summer here now?

Speaker 4 (00:53):
So jealous?

Speaker 3 (00:55):
Yeah, we got like really want we got to tease
really two really warm days last week during the kids
spring break, and then went back to the cool and rainy,
which it's great for skiing, didn't snow up on the mountain,
but not so much for everybody else.

Speaker 5 (01:09):
We had two rainy days.

Speaker 1 (01:13):
Yeah, this year we hardly had any any winter really,
it was mostly summer all year long.

Speaker 4 (01:22):
This year. I'm kind of springish.

Speaker 5 (01:24):
Just the best part of global warming. When the winter
is warm, it's enjoy.

Speaker 1 (01:30):
Yeah, so putting the weather aside, Uh, we are here
to talk about typescript.

Speaker 4 (01:38):
I guess in the context of oh no.

Speaker 5 (01:42):
Already we're already going to start fighting.

Speaker 4 (01:45):
Yeah, typescript.

Speaker 1 (01:46):
But I guess in the in general or in the
context of security, maybe both, maybe both. So I think
like everybody knows what typescript is, and from what I've
been experiencing and seeing, everybody is more or less using typescript.

(02:06):
I'm hard pressed to think about projects that don't use
typescript unless they're really legacy projects. Any new projects seems
to be written in typescript. Does anybody disagree with this statement?

Speaker 5 (02:21):
Absolutely secure standard.

Speaker 4 (02:25):
Please in the enterprise space, even not in.

Speaker 5 (02:28):
The enterprise base, I would say that even small projects
tend to start with typescript now for the sake of
the developer experience.

Speaker 1 (02:38):
Well, for the sake of AI, because you use an
AI tool to generate your code and it generates it
in typescript.

Speaker 6 (02:47):
I think before that, though, like you had, like even
starter projects, like the default for like astro, if you
wanted a blog would be like defaulting to typescript, and
you know things like that. So you'd think a framework
or some library and like it would default you to typescript,
and I think it would be if you weren't doing
typscript before, you'd like have to mess around with it

(03:09):
to figure out how to like don add to typescript here,
which maybe I know because I'm not naturally a typescript
but yeah, I also do agree like the typescript that's
kind of like taken over the system, and I think
that's okay.

Speaker 4 (03:26):
Oh yeah, by the way, it just said that you
switched audio devices for some reason, do you hear me?

Speaker 1 (03:32):
Yeah, yeah, yeah, it seems it's not coming through your
microphone anyway. Uh. Probably the only scenario where I'm probably
unlikely to use typescript would be if I'm doing something
like a lead code interview. Uh, and then I you know,

(03:52):
in that type of a situation, I probably just.

Speaker 6 (03:56):
Use photo, which is JavaScript essentially.

Speaker 1 (03:59):
Yeah, like you you're going for speed rather than for
type safety.

Speaker 6 (04:07):
I mean, I can I can tell you why some
of us maintainers hate the divescript part, which is for debugging,
which was a long time pain for debugging like currently
installed libraries like they're already like you know, went through
like the build phase and they're electron spiled and it's

(04:27):
it's a mess debugging it. So that was something that
was like, I mean, it's still kind of painful, but
as a maintainer or as a as a dev have
to maintain within the note modules package for older you,
you'd kind of get lost and really want to reap
all your herd out just because of it.

Speaker 5 (04:47):
Even though now everything changes.

Speaker 4 (04:49):
Yeah, yeah, I.

Speaker 1 (04:49):
Think we're on a better trajectory now a real We're
still not on your microphone though, I think I.

Speaker 5 (04:55):
Need to lock out and knock back, and.

Speaker 6 (04:56):
It's the JavaScript microphone.

Speaker 5 (04:59):
See see typescript bug. And I'm gonna log out and
log back in.

Speaker 1 (05:03):
No problem, We'll be waiting for you. So yeah, I guess.
I guess that's true in in the sense that whenever
you like, I think we had guilta yao on the
show like a long time ago, speaking about that very

(05:25):
fact about why he actually used to prefer jas doc
over over you know, using typescript because he wanted to
avoid the transpilation on the note side. His argument was
that on the browser side, you're going to have transpilation

(05:48):
anyway because of the bundling, because of JSX, so you
might as well do typescript as well. But on the
note side, where you could have just run the code
as you wrote it, Transpiling never adds value in that sense,
and I totally agree with that.

Speaker 3 (06:05):
Well, I don't know if you remember the whole big
stink that's Vell basically did that exact same thing, where
they've had a whole big announcement about we're getting rid
of typescript and what they started doing with jastocks, and
we talked to Rich Harris about them.

Speaker 5 (06:18):
I think we can maybe draw the line because jstocks
is still typescript. Okay, there's typescript as a language as
a developer tool, and there's Typescript as the transpiler, and
you can enjoy typescript on your ID even without transpiling,
which is what j stocks does, you're still writing Typescript.

Speaker 2 (06:40):
They are fundamentally different languages. JavaScript has a type system.
It has a finite set of types, and there's things
that you can and cannot do with those types. Typescript
as a version five has become much better at dealing
with JavaScript types. But Typescript was designed to deal with
C sharp types and to apply them to a browser,
and so the pattern of code that you get with

(07:01):
Typescript versus JavaScript is radically and wildly different. You cannot
easily write simple programs and typescripts, certainly not with AI,
but you can write simple programs in JavaScript because JavaScript
does not require complex type hierarchies and JavaScript type system
is not turing complete.

Speaker 5 (07:22):
But wouldn't you say that large systems have large type
hierarchies and require applications contexts.

Speaker 2 (07:29):
Why would they? Why would you need to have large
type hierarchies. That's the design flaw, that's not something inherent
of the system.

Speaker 4 (07:39):
I mean, look at GO.

Speaker 1 (07:40):
I think the large type hierarchies were an attribute of
Typescript in the early days, where indeed the language was
kind of directing you toward building class hierarchies. All the
examples at least were written that way. But I think
people are not have not been writing Typescript in this

(08:02):
way for a while now. Most of the typescript code
that I'm seeing can be thought of as JavaScript with
static types. People are not building these huge collections of classes,
and then with implementing interfaces and building Typescript that way.

(08:25):
I'm just not seeing it now. It might be because
of React, because React went with hooks rather than with classes,
or it might be that people just discover that they
could use typescript in a more JavaScript sort of way.

Speaker 4 (08:41):
I don't know.

Speaker 1 (08:41):
Maybe it's a combination of both, but that's the reality
that I'm seeing.

Speaker 5 (08:47):
I think there are also two like there are many
ways to use typescript. Yeah, you can take it in
the very c sharp like old schoolp way, but you
can also use typescript as just a tract maker, just
to define a contract that a function expects some contract
as an input and expects to return some other type

(09:10):
as an output, which is like defining contracts. And you
can also use typescripting like in a higher level, which
is to create an applications context. So if I have
a function that accepts a name and an ID and
another function that accepts an object with a name and
an ID, I can say that both functions accept the
type of person. And by doing this, I created a
context between these two functions. And I think that is

(09:34):
kind of what's big about typescript. And do you know,
do you guys know how typescript like, how did it start?
How did that start?

Speaker 4 (09:44):
It? I will let you talk about that.

Speaker 1 (09:47):
And by the way, there's a documentary about that but
before that, I do have to mention that these days
in Node we do have a building support for type stripping,
which effectively just erases the type out. So that means
that we can now use typescript files without transpilation with Node.

(10:08):
We don't have to use js doc for that purpose anymore.

Speaker 5 (10:12):
It's transpiled internally like it is still transpiled. It uses
an SWC plug in like it just transpis it internally
inside notes. The code has.

Speaker 1 (10:23):
Transponed obviously because at the end of the day, Node
is using v eight, which is a JavaScript engine.

Speaker 4 (10:30):
It's not a typescript engine.

Speaker 1 (10:32):
So it needs But it still means first of all,
the transpilation is basically just erasing the types. It replaces
the type declarations with white spaces, and the as I said,
the interesting or the useful aspect of it is that
you can use the same source files. You don't need

(10:54):
to go through a transpilation step before loading the files
into Node. What you used to need something like tis
snowed for in the past. You can just do it
with Node itself now. And obviously you can do the
same things with bun and Dino, So it means that
you don't need that the source maps to be able

(11:15):
to single step to the files anymore. You can just
use those files as is the same way that you
would with let's say, Jase doc. I'm just putting that
up out there. But now going back to your point
about that history of typescript that you were alluding.

Speaker 5 (11:31):
To just then, because for the haters, So the reason
why typescript was even a thing, Anders was supposed to
be joining the vis Co team that they were developing
viskode in JavaScript, and the moment he joined the team
and joined the effort, the first thing he suffered from

(11:52):
was it's impossible to really refractor without the context. And
he was like, guys, we haven't much bigger problem here,
and that's kind of how we started off building typescript
in order to help developers develop and out of his
own pain as as a developer. So like these days,

(12:14):
it is a human tendency when when we have something
to be when we have a pain, so to be
focusing on the pain. But there are a lot of
things that we do get a lot of value from typescript,
and there are trends, it's true, but I do think
that there is a reason why this is an industry standard.

Speaker 1 (12:35):
I think the bottom line I think is that to
the great to a great extent from again, from what
I'm seeing, but I'm the simple size is relatively large,
is the typescript one. I'm seriously not seeing any significant
new projects being started in JavaScript.

Speaker 4 (12:56):
None.

Speaker 1 (12:57):
It's not like one or two or here or there,
truly none. Every new project that I'm seeing is starting
being started in typescript.

Speaker 6 (13:06):
That's great, even more of a case to talk about
the security aspects of it.

Speaker 1 (13:11):
Okay, then do we want to talk to switch talk
about that. By the way, I didn't introduce you to
but because I forgot, but I think you both of
you are coming kind of from the security space, right.

Speaker 5 (13:26):
No, no, no, not from the security space.

Speaker 1 (13:29):
Okay, then correct then please correct me? What space are
you coming from.

Speaker 5 (13:34):
I'm a full sex developer. Typescript is my bread and butter,
so I've been talking about typescript quite a lot and
in the past two years. And it's also very exciting
to see the massive shift that is happening now in
typescript because the performance of Typescript has been a pain

(13:54):
point in many projects for the past two years, and
so it's just a topic that I really like, and
I teach and I give workshops about so that's kind
of why Duran invited me as the TS expert here.

Speaker 4 (14:12):
Okay, cool, and now about ju Leian.

Speaker 6 (14:16):
I'm a develop product at for Snake, so basically doing
a lot of education and security research in the node
and the travelscript space, I guess now effectively maybe officially
in the typescript space as well. But the Areela helped
me kind of like I think, sharpened some of these
ideas and really try to frame them for tiptream developerss.

(14:38):
I'm not, naturally, like I said, a type ship dev
obviously going to adopt this more and more with the
tooling and everything else. But it's it's been fun looking
at it coming from I think fresh eyes to look
at these problems. And I've had some which we'll talk
about here, I think, but I've had like my journey
into this really started with sharing something on social well,

(15:00):
and then like it got blown up as like a
really long tread with like what's they dodge from express
and stuff like that, and people lurking and asking questions afterwards,
and it became clear, like very evidently clear. Also by
doing a bunch of like social media polls that devs
view typescript in a very specific way, yet use it
in different ways. And the whole security part is it's

(15:24):
kind of meshed in between, but not in a really
good way. And that's kind of like I think the
premise for a lot of this discussion here.

Speaker 4 (15:32):
So can you elaborate please.

Speaker 6 (15:35):
Yeah, So it's basically started. I obviously share like a
lot of security related stuff and most of them is
like snippets and kind of like say, hey, this is
like there's a security issue here, can you spot it?
And stuff like that. And while we're on a medium
that's like not really easy to share a code snippet,
I can very clearly explain it. You don't have to guess,

(15:57):
so we can fucture it together. But it basically a
function for a template engine on a node not not
in Typescript at that time. This is like ten years
old or so. But it's basically something that escape htmls
HTML characters. And the function has this type guard where

(16:17):
it starts with like if type of you know some
string that I'm getting equals a string, then do something
and replace the characters, like basically turning them into HTML entities.
So it's effectively doing a sort of output encoding like
your favorite you know, react a framework would do. And
then there's like there's no else but but outside of

(16:40):
the conditional. So if if it's not a string, it
just exits it, and it's like, you know, returns the
string itself without sanitizing it or escaping it properly. And
so that's the that's the that's the that's the quiz. Basically,
that's the challenge. So I was posting that picture and
someone replied like typescript would have got this, and I
was like immediately like I don't think so, like why

(17:04):
would it have got this? And you know our social
media and internet goes or like yes it would, and
I was like, no, it wouldn't. And it became like
a long tread on blue sky, and you know, Wesley
thought was started. We discussed that, and I think that's
kind of like the promise, Like that's how it got me,
like why would it? And I was like actually testing,
like let's let's say, let's let's get a nice vulnerable
project up and running, run divecrip on it and see

(17:26):
if it works.

Speaker 4 (17:28):
And the real.

Speaker 6 (17:29):
Premise for like what's going on under is, which I
think it's it's an interesting think talking through the security
kind of like landscape or surface of developers using divescripts
and the actual real world vulnerabilities that come from it.
Also ZOD related to it as as a building block
is interesting. But my I think, I think what kind

(17:52):
of like hits it on the nail. And that's something
that's been very i think, very resonating with both me
and Wesley, was that if it seems that developers kind
of like you know, feel about typescript and put misplaced
trust on typescript in the same way that they put
misplaced trust on code coverage, meaning they think of it

(18:14):
more than it should they should, and they think of
it as a security tool. And I think that by
itself is while touchscript is, you know, like any strongly
type language is helpful, it's not a security tool by itself,
and that creates a fallicy and that is something that
I would like to to change and maybe should do

(18:35):
this conversation on this, you know, on this session, I
can give you several examples of why that happens and
how that fails developers.

Speaker 1 (18:43):
The fact that you said that people put trust in
code coverage in the context of security reminds me of
that old joke about QA and engineer working for a
bar and ordering one beer, ordering zero beers, ordering million beers,
ordering a hammer, ordering a ray, ordering yeah. And then

(19:08):
and then the first customer walking in asking where the
toilet is, the bar blows up and kills everybody inside.

Speaker 4 (19:16):
And the one yeah.

Speaker 1 (19:17):
So so that that grows to show like.

Speaker 4 (19:22):
The value of unit testing.

Speaker 1 (19:24):
Let's say, in the context of app of application security.
I mean, I guess it's it's better than nothing, but
but not by much.

Speaker 5 (19:35):
There are a lot of controversial posts about I wouldn't
mention the name, but how teams replaced a lot of
unit tests because they have typescript.

Speaker 4 (19:45):
Now, m.

Speaker 5 (19:48):
On that.

Speaker 4 (19:50):
If the unit test is there, why replace it?

Speaker 6 (19:53):
I mean time, I'll give you no better. Let me
like you build another one on our else. Take. Now
we said like if you have a typescript, then you
maybe don't need tests. Well how about this. I have
a take where someone said we don't need zoo if
we have typescript and stuff like that. That's that's you

(20:17):
know that, that is where this is happening. And this
isn't like a random person, you know, getting pulled out
of like ten thousand. There's a lot of confusion. Let me,
let me pull up something. Wait, let me So I've
pulled and I was was asking, when do you work
on typescript code base? What is your level of ecosystem depth?

(20:38):
And I gave three options. One is just typescript and TSC.
The way that, for example, maybe I would use it
as like a beginner you mean for type checking the man, yes,
just type checking. You just you know me as a
bit like I said, I'm beginner developer with typescript easy
you know, you know, adapter for it. And the way
that I would just like, you know, type my of course,
have like a typing system type my data parameters and

(21:01):
run a typescript checker compiler for it. So this is
option one, and like fifty four percent of developers chose
that one. The other two options was typescript and type
narrowing also known as type cards, And the third option
was typescript and narrowing and ZOD. And obviously, I think,
like among the other experts here on typescripts like maybe

(21:24):
more that you could pull into the ecosystem. But I've
read this pollic quite a few times and it's always
the same answer, like at least half of the people,
if not more, really just us typescript as the compiler
and the checker, nothing beyond it.

Speaker 1 (21:38):
Look putting ZOD for a site for a minute, and
I think that would actually be the crux of our discussion.
But before we dive there, type narrowing to me is
part and parcel of typescript. I don't see the exact
difference between number one and option number one and option
number two, like you said, just typescript versus types of

(22:00):
the type narrowing. How is type narrowing not just part
of typescript?

Speaker 5 (22:05):
It means if you do runtime checks about the times, Yeah.

Speaker 1 (22:08):
I understand, I understand what oh you mean, like specifically
doing lots of tests using type of exactly constructor equals
and stuff like that exactly and which.

Speaker 6 (22:20):
Is not dipescript, you will even if you just do
pure JavaScript. But I think that's you see, But that's
that's the exact fallacy. Like developers don't they think they
don't need to do this runtime security of type of
even before we go to that, like you said, because
they use a type system, because the compiler is fine.
And someone gave me a screenshot where they show me that, uh,

(22:41):
the request imagine like let's talk let's talk back end
and servers and express and typescript, okay, because that's like
the easiest uh you know attack surface here. So if
you use that, you have a type request, right, and
the request may get like requests or filter strings and
stuff like that, like maybe a filter and maybe that
is typed as a string or something like that, and
then all the types that kind of like you know

(23:03):
that string is is flowing through the code flow to
the code path in different functions. And they show me
and they say, hey, you know what, I can't even
write a vulnerable function because it only accepts types and
typescript safety because of the compiler, and I would find
it on CI and I was like, no, it's won't
because like runtime is not dev time. You can't make
that assumption.

Speaker 4 (23:24):
Even dev time is not dev time.

Speaker 1 (23:26):
And I'll touch on that in a second, but yeah,
I think that's the key point that we need to
explicitly make. In case it's unclear to anybody who's actually
listening to the podcast, pypescript type checking is done only
at build time. It is it has zero impact on

(23:48):
runtime Pipescript does not do any type checking at runtime.
And that's an intentional feature of Typescript. It's not a bug,
it's a feature. That's how Typescript is built intentionally. So
anybody disagrees with this statement.

Speaker 5 (24:06):
I like it. When I give talks about Typescript, I
like to talk about the development space, and I call
it the development matrix because in run time, which is
the real world, like, the types don't exist. And it's
kind of because a lot of us are really as
we said, it's standard, and projects start off with Typescript,

(24:28):
and people that are beginner developers they see that you
can define what shape of an argument it's going to be.
It is quite confusing at the beginning to make the
difference that the code that you see as the developer
is not the code that would run. And that confusion,
that matrix is really the root of all of it.

(24:50):
And we can even take it to many other spaces
in development these days, when things are layers over layers
over layers, develop beginner developers see the upper layers and
not everything that composes underneath. So I think this podcast
is finally important for any beginner developer listening that might
be confused about it.

Speaker 6 (25:13):
I think experience developers who are like fifty typescript poll, well.

Speaker 1 (25:20):
You know, whenever we whenever anybody speaks about experience or
senior developers versus junior developers, I'm reminded of the fact
that every like poll about JavaScript shows that the Java
the median experience the JavaScript developer has is something.

Speaker 4 (25:38):
Like three years.

Speaker 1 (25:39):
So half the developers have less than three years experience.
So half the developers would be considered junior, I guess,
but at least half. But going back to the key
point is we were talking about how Node now supports typescript.
It supports Typescript by type stripping, So I think that's

(26:00):
the best way to think about it. The run time
of typescript is just all the types gone. That's the
run time of typescript. It's that's the JavaScript that comes out,
and that's key to understanding this aspect. But going back
to what you said about the developed the safety at

(26:22):
the time of development, if that's a bit of a fallacy,
or let's put it differently, it's a fallacy if you
have any any in the code, because once you've got
even a single any in the code, anything that goes
through that comes out of the other side without that
type context, and then it might have been a string

(26:45):
coming in, but it can be a number coming out
and that kind of propagates throughout the code like a
single any can have a wide ranging impact across your
code based depending on where it is in the code.

Speaker 6 (27:00):
Taught because I was doing the exact same thing in
my in my slides for I have like an upcoming
talk on this. So I was doing the same thing
and I was like, oh, rel, I need your help
reviewing this our dipecript expert, and she was like, Okay,
you're using any here. You know, like a lot of
beginners and sorry, a lot of experienced users of typescript developers.
We'll see it and we'll tell you it's it's it's

(27:21):
like a basic problem.

Speaker 5 (27:22):
It's a bad practice.

Speaker 6 (27:23):
Yeah, like don't do it. And I was like, okay, fine,
let's not do it. Let's I'll put I'll put string
and I'll use the I've used requests, you know, request
body or request quarry. That's that filter as string too,
But that fails too, Like that will not save you either.
Whatever you type it.

Speaker 1 (27:41):
That's when you say, as you're basically telling typescript. Trust me,
you don't, you can't figure out what the type is.
Then consequently I have to tell you, and I'm telling
you that it's this, and you've got to trust me
on that, and maybe you're right and maybe you're wrong.
But but it's kind of like sort of a it's

(28:03):
it's time. It's typecasting, and typecasting is unsafe in every
language that supports it, but not just not just typescript.

Speaker 5 (28:12):
And it's also inevitable, like because the alternative would mean
that you don't have a way to when it is
necessary to detail typescript. What is it?

Speaker 4 (28:23):
Yeah, for sure.

Speaker 1 (28:24):
I recently I'm working on we were talking about existing
code bases that are in JavaScript. I'm one of the
projects that we have at work is a fairly large
legacy JavaScript code base, but it's still under development. So
there's value in migrating it to typescript, but it's going
to take a long time. I was looking at a

(28:45):
piece of code and I was kind of forced to
do as are known as X.

Speaker 4 (28:50):
So I have a.

Speaker 6 (28:50):
Question, is that is that a bad thing? Like should
I not use as string for example?

Speaker 4 (28:56):
Well, so here's the story.

Speaker 1 (28:58):
So I was I was want to do something, and
the only way I could get the code to compile
was doing something like as a known asterisk, which annoyed
the heck out of me because why do I have
Because when I do something as unknown.

Speaker 4 (29:13):
It feels like I feel like dirty.

Speaker 1 (29:15):
So I reached out to the number one typescript expert
that I know, which is Matt Pocock.

Speaker 4 (29:20):
I assume you've heard.

Speaker 1 (29:21):
Of him, and I told him I'm doing this disgusting
thing in this code snippet over here. Do you have
a suggestion for you know, something nicer than I could do?
And he said, if that, what, if that, what's work?
Just go with it? Because because he said, don't don't
overthink it. If it's localized, if it's small, if it

(29:44):
gets you, if it gets a job done, just go
with it. So so, yeah, sometimes you know it exists
for a reason. The language supports this idiom because it's needed.

Speaker 5 (29:55):
There are no way bad practices, there's only a context.

Speaker 6 (29:59):
For sure, well kidding.

Speaker 2 (30:02):
The typescript checker does get better, Like version four was
very very bad at understanding JavaScript types. Version five is
incredibly improved and understanding those And I think that as
it goes forward, I would hope that there will be
a point when the idea of typescript would just be
redundant because if the Typescript checker gets better and better

(30:24):
and better at doing JavaScript, then you wouldn't need something
like any because it would just be able to introspect
and look at the code. See what she returned.

Speaker 4 (30:34):
See.

Speaker 2 (30:35):
You know, there are some idioms you have to follow,
Like you can't just willy nilly add a property on something.
You need to use object out a sign if you
want to add a new property that didn't exist before.
But if you use object out a sign, for example,
whatever comes out on the other end of that. If
you add something with name, age, and birthday on one
side and you do object out of sign social security number,

(30:57):
the object you get out on the other side now
is correct and it will have all four properties on it.
So there's a lot of stuff that that as as
time goes on. I think that the reason ay exists
is I believe just because Typescript started out not to
be a JavaScript type checker, but to be a new language.
And and as that gets closer and closer to how

(31:20):
JavaScript works, yes, you'll still need to do annotations, and
you know to some degree, but I think it it
could get. It could get as good as zig Let's
say that.

Speaker 1 (31:31):
Yeah, but here here, here's the thing, though, I agree
in the sense that the basically what I understand that
you mean by Typescript understanding JavaScript types is that the
static analysis mechanism has become much better. It can track

(31:51):
the type. You know, JavaScript has very dynamic and malleable types.
It can track these things and figure out what's going
on and basically assign the accurate type at build time
based on what it figures out that the run time
will be. But there's a limit to how much you

(32:14):
can figure out with static analysis. It's not my area
of expertise. I'm not a compiler or type system expert.
I think what the people at working on typescript have
achieved is pretty remarkable, a lot more so than people
give them credit for. It's much more sophisticated than the

(32:35):
type analysis that's built into a lot of typed programming
languages statically type programming languages. But there's still a limit,
especially given that JavaScript itself is like the poster child
for dynamic types. It's like everything in JavaScript is as
dynamic as it can be. So what Typescript does I

(32:57):
like to The analogy that I like to use is
that it's like hurting cats, and there's a limit to
how much the cats will respond to your your instructions.

Speaker 4 (33:10):
Exactly.

Speaker 2 (33:11):
But it's kind of like JavaScript the good parts, right,
Maybe we need a JavaScript the type parts, because certainly
you can't use every feature of the language and have
a coherent type system.

Speaker 1 (33:25):
It's kind of happening. It's kind of happening naturally, because
what I've seen, what I'm saying is that certain JavaScript
idioms that were really, you know, fairly commonplace when people
were writing in straight on JavaScript, were less typescript friendly.
And now these days, where everybody is essentially writing typescript,

(33:47):
these idioms are not being used anymore, or alternative idioms
that are more typescript friendly are coming along and replacing them.
I'll give an example. In the past, we will you
would create an object and then you would do if
if something, then add property X to it. If some

(34:09):
other things add property why to it, And typescript doesn't
really like that. It doesn't like the fact that you're
adding a new property to something that is considered as
a mpotent close kind of closed type. So people are
starting to do things like they're spreading objects into the

(34:31):
initialization just so that Typescript can better figure out the
actual properties and type the actual properties that are associated
with that particular type. It's kind of difficult to explain,
you know, without actually showing code. Hopefully I've kind of

(34:51):
made it clear. But when types are modified in run
time using imperative code, it can be fairly difficult and
sometimes impossible for typescript to properly track the type.

Speaker 5 (35:08):
The way the typeescript handles these things, by the way,
the terminology for the static analysis is inferring when we
talk about type the types of how typescript analyzed like
does the setic analysis. So the terminology is inferring. But
the thing about the way typescript handles types, it kind

(35:32):
of takes the safe way. Okay, So let's say I
have an If something happens, then add property A, and
if something help else happens, then add property B. So
the way type stript would infer this thing is that
this object has both A and B like. I like

(35:53):
to call it the shreddingers union. So it's both A
and B like with only with the and the only
way for you to narrow this down is within a
certain scope to make an assumption. And that's also the
reason for the pattern discriminated union. It maybe you guys know,

(36:14):
so for the listeners that don't know what discriminated union is.
So because of what I just explained, that types will
take the widest type possible because in development time, it
can't really know what would happen. There's a pattern called
discriminated union. So if I have a union of types,
so let's say I have a property or the property,

(36:37):
the way for me to help type script and help
it narrow it down is by adding an extra key
that the key would not overlap any other keys in
the union. So let's say, for example, I have property
A is something, and then I would have key is
true and then the other type I'm merging into I'm saying,
or other types of property B, and I would say

(37:00):
that the key is false. True and false don't overlap.
So I can when whenever I check this object, and
I would say if key is true within that scope,
typescript knows the type narrow down. Typestrip knows which which
type it isn't. That is kind of maybe like a
new idiom for handling.

Speaker 1 (37:21):
Yeah, so That's one example. There are several such examples.
The bottom line is that I'm saying that, especially again
when I'm looking at older JavaScript code bases and I'm
moving them to typescript. Ideally it should be just about
adding types. In reality, what I am saying in that

(37:41):
is that in a lot of cases, I, in order
to add types in a way that is actually useful
or sufficient, I end up massaging the code. It doesn't
stay exactly the same.

Speaker 5 (37:55):
You can say the same thing about tests. How do
you mean that sometimes you might find yourself changing the
code to make it testable.

Speaker 1 (38:03):
Yes, although a lot of times when it happens, I'm
really annoyed with it because it usually means that people
are testing internal things that and then are exposing them
to the outside just so that they can test them.

Speaker 5 (38:16):
Or just bad dependencies.

Speaker 2 (38:18):
Yeah, but the correct to the point earlier of the
I already forgot how you called it that guards or
the union, the discriminate discriminated union. So obviously this is
something that people want to do. It's not something you're
going to beat out of people. But metaprogramming is a

(38:41):
code smell. There's a certain I don't know, I guess
I'm not really a fan of dynamic programming. The way
that I program JavaScript is the way that I program
go And if you need something to return a different type,
then you should just have a different function, you know, if,
rather than have one function that handles many different cases
and then have metaprogramming inside of the function, just split

(39:05):
it out into separate functions.

Speaker 4 (39:07):
I'll give you an example, though.

Speaker 1 (39:09):
The common example, where the canonical example almost of where
you see this sort of thing is where you have
a function that has a success It returns either a
success value or an error value with an explanation, and
you've decided not to use exceptions, so you're actually returning
an object that either has the result or has the error.

Speaker 4 (39:33):
So you would have a.

Speaker 1 (39:34):
Discriminating field saying that success or failure, and then based
on whether it's success or failure, you would have the
fields that are associated with the success in the object,
or you would have the fields that are associated with
the error, like the error code or the error text
in that object, and you would use that discriminating field

(39:55):
of success or failure to know what the other fields
in there are.

Speaker 2 (39:59):
This is already been solved, though, Like we already have
a tupule pattern for this, where the first element in
the tupole is your success object and the second element
in the tupol is your air object. So and you
can return toopoles in JavaScript.

Speaker 1 (40:12):
Yeah, but again the reality is that in many cases
you first of all, you're first of all you're correct,
and also, like I said, you could just use exceptions instead.

Speaker 2 (40:24):
Yeah, and I think that that that's why I'd say
that to me, sounds like an anti pattern. I know
why people use the tuple, especially if they're coming from
go or or Rust or another language where it's common
to use tupuls to to emulate option types or result types.

(40:45):
But yeah, I my my biggest question to be why
aren't you using air handling to your best advantage.

Speaker 4 (40:52):
I'll give another example though.

Speaker 1 (40:54):
Suppose you have a reducer and you have the action
and the data and data that you pass in varies
based on the action. So again you would use the
action field as a discriminator and then the other field
and the object depends on the action that you're doing.
There are a lot of situations in which this kind

(41:15):
of in JavaScript, you would just pass an object in
and then you would effectively do runtime introspection. To figure
out what it contains. Typescript tries to add static type
checking on top of that, and in JavaScript you could
often make do without that discriminating field because you would

(41:36):
just check whether particular property exists or not, like you
know has on property, et cetera. Typescript encourages you to
have this kind of discriminating field that is more explicit
about it.

Speaker 5 (41:49):
Also, a question like the tuple has a lot of
advantages to it. But wouldn't you say that if success true,
like is a bit more readable than in place zero
or in index one?

Speaker 2 (42:05):
No, Because you mean, if you're going to do that,
you're going to do the deconstruction, right, So you're going
to do let bracket result common error bracket equals. So
from a readability perspective, I I don't know how it
makes a difference, because I mean I have not seen

(42:25):
anybody do it without deconstructing, right. So, first of all,
it's not a pattern. It's not a pattern that's widely used.
It's interesting, I there's a now they've got there's something
in the pipeline for this pattern. I don't remember what
it's called. But in the JavaScript standards right now, there's
something in the pipeline for this, but it so that

(42:48):
you don't have to do the square brackets and it's
like it's like a special I don't remember what the
syntax is, but it's like a special type of a
weight where you where you get the ghost style slash,
rust style old slash.

Speaker 6 (43:00):
You can just distract the error without the whole try
catch block.

Speaker 2 (43:05):
Well, you can do that. You can still do that anyway,
because you could just put a dot catch on there
and then you can do if type of error.

Speaker 6 (43:14):
Yeah, that that proposal isn't Yeah.

Speaker 4 (43:16):
I know what you mean.

Speaker 6 (43:17):
I know that proposal is.

Speaker 2 (43:19):
It is it?

Speaker 6 (43:19):
And I think it's it's coloring that practice with the
dot catch as as not a fancy one either, which
is why it's proposing that you could like do the
ghostyle for a bit.

Speaker 2 (43:30):
Well, I definitely hope that it fails because I don't
think that's an idiom that we need to bring in
the JavaScript amazing. I think we have the problem with
JavaScript is it's everything to everyone and nothing for no
one to.

Speaker 4 (43:46):
Be fair, and it's hard to get right.

Speaker 1 (43:48):
It's it's kind of it's kind of we're digressing, we're
going down a rabbit hole. But I sent you brought
us there. So I'm in contact on on X with
one of.

Speaker 4 (44:02):
The with Rob Palmer.

Speaker 1 (44:04):
He's one he's like the co chair of the TC
thirty nine. And he was talking about and he regularly
posts about new things being added into into JavaScript, and
he like titles it JavaScript excitement.

Speaker 4 (44:20):
Uh.

Speaker 1 (44:21):
And the last so I was kind of being intense
intentionally facetious when the last time that he did it
about like the entire year, and I said, and he said,
like typescript excitement. And I said, I'm looking at your
proposals and there's nothing much exciting here. And he was
going like, like, how do you mean, And I said,

(44:41):
because these are all like these are all like library functions,
like you now have this extra method on type of
string or this extra method on type of array. There's
nothing like sorry left bad, left bad exactly. Uh.

Speaker 4 (44:58):
There's there's nothing like.

Speaker 1 (45:01):
Similar to when you added a sinka weight, or when
you added constant let or when you added erow functions.
And he basically responded seriously by saying, yes, we are
intentionally winding down the amount of syntactical changes to the
language that we are making. We are at this point
in time of the maturity of the language where we

(45:24):
really hesitant about adding new stuff into the actual syntax
of the.

Speaker 5 (45:29):
Language, and they have Typescript now.

Speaker 1 (45:32):
Yeah, but look, there are certain proposals that a lot
of people are pushing for and are still stuck maybe
because of that stuff like the pipeline operator, which has
been kind of waiting in purgatory for something like three,
four or five years because it requires a significant change
the syntax of the language. People have been talking about

(45:55):
all sorts of pattern matching capabilities that aren't happening, again
related to actually changing the syntax of the language. But
again we really digressed, going back to your pointly run
about the fact that the majority of the people assumed
that not necessarily made it conscious assumption, but based on

(46:17):
the way in which they write their code, assume that
Typescript provides them with type security run type type security
that it does not. And we talked about one fact,
which is if you're using any in your code, and
it's not such a weird pattern because again, if you're
taking an existing code base and you're moving it from

(46:39):
JavaScript to typescript, it's really hard to get rid of
all the nis.

Speaker 5 (46:46):
It's also what it's for I must say that's what
the type trip team. I say any is for.

Speaker 6 (46:51):
I will, yeah, but I will. I actually don't want
to give people like a discount and say Okay, if
you use any, then you get it. It's not that
if you use as string, the same problem. If you
use interfaces and you infer data or the aque you
point to data from an interface, exactly the same problem.

(47:12):
So I want to I'm here to like raise the
awareness of typescript and its follicy and security. And if
we just say that it's because you use any or unknown,
then we fail that because whatever you use to type
it on the typescript side of things. If you use interfaces,
I don't know all your Union stuff, branded types whatever.
Actually wait, Brando types has a in which this actually

(47:36):
does work if you can like assert it on run time.
But if you don't do that, and you'd still use
interfaces and everything else, and you use as string and whatever,
all of that fancy typing does not save you from
having runtime security issues and type juggling vulnerabilities.

Speaker 1 (47:52):
Does that have to do only with when you're sending
information over a medium like you know the network, or
does it also just happen in your in the code itself,
Like what's this sort of problem associated with?

Speaker 6 (48:11):
So obviously like the easy use case here, you can
of like simulate this is where you want. And this
is like a general concept in application and security, right
like you whatever you put as as like your own
data or you know you're trusted data, that that's fine.
Like I can like as an attacker, as an external
entity to the system, maybe I can truly manipulate it

(48:33):
and do anything with it. Which is why I'm kind
of like taking the example to what is the most
common scenario with application development, which is you're having servers
and servers get data from somewhere and that's usually data
that flows over HTP requests, okay, and so that is
where data comes in. And that data can come in there,
but it doesn't have to come in there. For example,

(48:54):
maybe you save user names sorry, file names and I
don't know, in the cloud somewhere, okay, a very strict
way without pat reversal, without anything else. But that data,
you don't manage it in any other way like you've
you've saved it in some way it doesn't impact the application.
But then in some other place in your application you
actually use it and trust it, but that file name

(49:16):
was saved by you don't know it at that point,
right that imagine the developer working on that other system
or other component of the system. They treat the data
from the database or from like a bucket name as
potentially safe, but it's not. I can give the exact
example with Git branches. Do you know that you can
actually have a semicolon in a Git branch name, which

(49:37):
imagine now that I'm telling you go ahead and get
clone or get checkout to my leran semicolon rm you know,
percent twenty whatever to your ref your entire directory. You
will actually if you run this on a shell, you
actually have shell meta character interpolated, and you will not
just do a Git clone or get checkout actually, because

(49:59):
that wuch name is valid by GitHub, will actually run
a command. So this is where the typing system kind
of like you know, it stays on the development side,
and it's easiest to give you those by juggling.

Speaker 4 (50:13):
Yeah, little Bobby tables.

Speaker 6 (50:16):
Yes in different ways and unexpected ways, which is why
I'm kind of like wanting to hit that with a
hammer and say, like type scrift is not a security
at all. Like, I appreciate it, but I don't want
you even though it gives you strongly typed security benefits,
if you want to take it there, I am happy
to give you that concept, but I don't want you

(50:38):
to think of it as a security tool because the
moment you did, you'll have those mistakes done, like not
understanding that it's not on run time and all of
these other issues.

Speaker 5 (50:46):
So if it makes fun of type scriptures not being
strongly typed, quality, weekly typed, or strongly typed, that's my favorite.

Speaker 4 (50:55):
Awesome extremely typed. Had to hear that.

Speaker 5 (50:58):
Strangly type because US trends are equal, because it's it's
an because it's a duct type, it's not a phenomenal
type system. Well.

Speaker 1 (51:07):
I think the bigger issue though, is the fact that
we're we're kind of used from JavaScript of working with
data in kind of blobs like you've got to json,
and the JSON is effectively a JavaScript object and it
can have any structure in any fields, and anything can

(51:30):
be hung on it, and the strings can be any
and can be anything, and so on and so forth.
But to be fair, this is not just a typescript thing.
I mean the amount of times that have written type
safe C plus plus code and have run into situations
where the bits and bites didn't exactly match what I
expected them to be.

Speaker 4 (51:52):
You know that that happens.

Speaker 6 (51:53):
Yes, But there's a there's a big difference between like
if you'll malock for whatever, like any bytes versus forty bytes,
or you forget or not do it correctly versus you
actually interpret a string as an array or an object
because that flows through the systems and can wreck havoc.
And we have like this, this is this literally has
like its own vulnerability class called type juggling, which PAHP

(52:18):
developers know it because you know PAHP, but also JavaScript
developers should know it because also JavaScript.

Speaker 1 (52:24):
So can you again elaborate a little bit about type juggling.

Speaker 6 (52:28):
Yes, So let's take let's go back to like our
simple case. We have an Express server running with typescript okay,
and we only use type twitter. I'm not even going yet.
We haven't crossed that phase of using type know ring,
which we should probably get through and then zod, but
we haven't crossed to that part. And imagine we're building
something as simple as like a React like a poor

(52:50):
man's React server component sort of things So imagine you're
having a request coming in. You want to take the request,
you want to check that, maybe call a function as well.
If it's sanitized, everything is a string, you know, the
username is a string whatever, and then that that server
response is basically an HTML object back to you that says,

(53:10):
you know, hello world or hell low arel or whatever,
and you type it all the way and you do
the sanitization. But if I'm sending you, if I'm sending
you now like the in the Corey string, I'm doing
name square, brackets equals and then start an image tag
like an actual HTML image tag. Because of the way

(53:31):
that express is set up, what you'll actually get is
an array interpreted there and then all of your typing
systems within your express and touch tip doesn't help because
now the system, the application itself, interprets this name as
an array and not as a string, and that is
type job. That's like the pure example of from an

(53:53):
attacker perspective, that's called HTP parameter pollution. Because we're able
to kind of like you know, fuzzy test, create kind
of like a mutation testing sort of on the request itself,
but to the application itself, it is actually being being
juggled from one type to a different one. And that's
a very classic one that happens a lot of time,
a lot of time.

Speaker 1 (54:13):
So basically, just to clarify, you were using typescript typecasting,
which is the as key word to tell typescript, trust me,
this is a string, because you assumed that it's a string,
but in reality and run time, it was actually an
array rather than a string. So you were telling typescript

(54:33):
this is a string, but it actually turned out to
be an array. And then from that point on, flowing
throughout your entire code base, it's trying it, it's treating
it's it's the assumption is that it's a string, but
it is it correct?

Speaker 6 (54:49):
And now and now imagine that your sanitized function to
this controller or whatever you want.

Speaker 4 (54:54):
And again, oh, one more thing.

Speaker 1 (54:56):
And of course typescript does automatic jobscript does automatic conversions,
so that when you actually try to use it as
a string, it will be transformed into a string. But
if you do certain sanitation functions that will only sanitize
the first part rather than the entire thing, maybe.

Speaker 6 (55:14):
Yeah, yeah, you don't have to cast it. That's where
I'm at. So you imagine that that sanitized function again,
have the function signature says as string and everything, so
that shit goes fine. But now that array flows through
the system function as an array. But when it hits
something like you know your your disallow list or the

(55:35):
name the data itself that includes, and then you give
it that input, that actually will get coerced from from
with a two string function from an array to a string,
and you will get the first element because that's just
how it works, and you don't know this ahead of time.
And worse than that, if you type check the system,

(55:56):
everything will be will match just fine, and your units
will work just fine because it's typed throughout the system
as a string. And I want to also correct on
because it doesn't matter that you lie to job to
typescript and tell it as a string. Because if you
define an interface or you rely on the the query
parameters of the interfaces as exported by by Express or

(56:17):
any other framework, that will also not save you because
you will get to the exact same problem we're talking
about front time.

Speaker 5 (56:24):
Let me maybe help sharpen this up a bit. An
Express for example, so the data that you accept from
a request, you don't have to like cast it that
cast is known as like a bad practice where you
tell it as a string, like if you just type
the argument of the function like requests expresses request, the
type is a generic type, so you can be like

(56:45):
request should accept a user of some interface. Like you
don't even see the bad practice here, it's just like
you're actually doing a good practice. You know, you have
you type the argument of your function. But on this
entry point of the application where you just accept the
request for type stript it's any and that's where type

(57:06):
shrip expects you to type it. But this is where
like it gets confusing because you think you're going on
press practice because you type your argument. But on the
other hand, typing a request without actually doing some run
time validation is a bad practice and it's not very common.

Speaker 6 (57:25):
I don't actually want to cross that chasm. Like let's
let's cross and say let's go to like that phase
and say if we did if if the run time
type checking is the type narring okay, or that what's
so so known as like the type cards that if
type of Like what do you think of that? Because
I have my own opinions, but what do you think
of that?

Speaker 1 (57:44):
Well, first of all, there are a couple of issues
with that. First of all, it's unfortunate. First of all,
it's kind of bad practice in JavaScript, again, putting typescript aside.
In JavaScript, I always considered it kind of bad practice
to have to do to write this type of code,
because the whole concept of JavaScript was about duck typing

(58:10):
about how something behaves rather than exactly what it is.
So creating these kind of switch statements or if if
l if l if ls based on the type of
a thing basically kind of indicated that it was. I

(58:31):
kind of thought of it as a cod small. But
that being said, stuff coming in over the wire cannot
be trusted. So there are certain points on the edges
of the system where I feel that type these type
of type guards are a must within the application itself.

(58:53):
I would strive to avoid the need for them as
much as I possibly can in terms of just the
way that I write the code.

Speaker 6 (58:59):
I resonate with that, and I'll just add another clarification here,
because I see how like, how like some security some
security aspects are kind of like creeping in here and there,
Like you're very concerned about something that's on the wire,
and I want to give you an example of a system.
Imagine you're building the WebAPI for things and you're typing
everything and it goes through the schema and everything is perfect,

(59:20):
not cynically, it is perfect, and you're saving something and
you're putting that data into a message bus. Okay, it's
going into a queue, and some other system gets it,
and that system could say something that got into the
queue is our internal system. That user name or that
email or something, that file name is a trusted data
because it's not over the wire. I'm actually getting it

(59:42):
from like my own rabbit and qure whatever. And that
is exactly where things fall apart because if you're not
using any actual security controls and measures on that end
as well, and you're having that concept of it's not
over HTP, it's not over API. No one is sending this.
This is not user input. I'm literally taking off of
the file system, off of the message queue, off of
you know, something that I presume as trusted because it's

(01:00:06):
our I don't know, internal thing, it's an internal service.
That is where things also, you know, break apart. Why
the same thing because that data flowed in my file
name flowed into the system, and you could have typed
it and said okay, it's supposed to be a string,
and you saved it as like an image that you
will manipulate later and find like it. There's no sco injection.

(01:00:30):
When you save the file name, whatever you put it,
you put it in the database. You also created a
queue on You started the que with the event over there,
and that system gets it and does something with it.
Imagine that's like a worker and asking worker offline. Worker
that takes that data and now it's it needs to
do something with your image, like manipulate it, like recize
it or whatever. So maybe it goes off and does

(01:00:52):
and does something like you know, an OS command to
run something like image magic or something to convert it.
Then it takes that file name and puts it on
this and the moment it did that, it trusted the system.
What if my file name is literally called they run
that jpeg semicolon rmnus r F exact same problem.

Speaker 4 (01:01:09):
So it's still it's still a.

Speaker 6 (01:01:10):
String, but it's now in a different context abusing you.

Speaker 1 (01:01:14):
So I want to verify that I understand what you're saying.
What you're saying is anytime code, anytime I put data
outside the direct control of my own code to an extent,
my ability to trust that data goes away. It's because

(01:01:35):
if some other part of the system gets compromised, now
I'm vulnerable to that compromise.

Speaker 6 (01:01:42):
There's just like a lot of a lot in play here,
Like this isn't type juggling. This is I was just
like specifically like going with a needle on what you
said were like you were like very concerned and conscience
on the transport like the htplay. But from saying it's
more than that. So I mean the way you probably
have done it better is you have like proper security

(01:02:03):
controls and secure coding. So the way that you would
do an OS command, like an operating system command, we
just need to be in a more secure way and
then whatever the data is, it wouldn't impact you. So
there's like a bunch of things in play here. What
you said is not incorrect. It's just like there's a
complete answer. There's more than just one thing that needs

(01:02:24):
to go and that is that's like that's related also
to a lot of concept in security, like defense in depth,
you have to like have several layers of defense and
security controls and security measures, and for example, a lot
of people think, hey, let's just sanitize all the data. Well,
that doesn't that's not how you know, real world works.
You don't really have to sanitize all the data. For example,

(01:02:44):
when you put user input as like an image, you know,
and a very bad like xtmil image tag, and you
give it to react, it doesn't sanitize the data for you.
It does something else that's called output encoding. It converts
the data into xtamil entities. That's a whole different and
concept from sanitizing the data. The data remains the same,
but the way that it gets interpreted on the dome,

(01:03:06):
the way it's sweetened to it changes. It's not sanitization
because the source of the data remains the same.

Speaker 1 (01:03:12):
Do want to move on because we're starting to run
out of time. I do want to touch on the
type cards and on those.

Speaker 6 (01:03:20):
Dog let's talk about zod okay. I have nothing else
on type pards like this is I was curious about
your opinion. I, by the way, resonate the same. I
love the duct taping, but I just feel that it's
like it's really hard to maintain a lot of type
if type of and I can't like agree with that.

Speaker 1 (01:03:35):
And and By the way, type off is not enough
because type off is like a very rough knowledge.

Speaker 4 (01:03:41):
It's a snedgehammer. You need. Probably you need instance off.

Speaker 1 (01:03:44):
As well, and from what I know, like half the
JavaScript developers at least don't really understand how instance off
actually works. But putting that aside, that's a different discussion.
Let's talk about zode.

Speaker 6 (01:03:56):
Amazing, Let's talk about zode.

Speaker 5 (01:04:01):
It's one of my faves, and I talk about this
quite often, so for the listeners that don't know ZOD.
ZOD is a very cool way to kind of bridge
between the development time and the run time. So it's
kind of a bridge between typescript and jobscript. So it's
basically a schema validation library that is what's called typescript first.

(01:04:26):
So the idea is that you define a run time schema,
so you're defining a schema that would check the object
in run time, and ZOD exposes a method called infer
which allows you to create a type out of your
run time validation. So basically you kind of have a
single source of truth primarily define your run time validation,

(01:04:50):
and you also get the type inferred out of it.
The reason why SOD is called typescript. First, it's kind
of because it's kind of leading in the industry in
terms of how handling more complex types, so beyond the
basic adjacent ZOD is very good at inferring union types
and et cetera.

Speaker 1 (01:05:10):
But also not familiar with ZOD, but maybe familiar with React.
ZOD in a certain to extent is kind of reminiscent
of the prop types that we used to have in
in in React that that also did run time type
validation when you were running in developed in development mode.
So it's not exactly the same, but there were a

(01:05:32):
lot of similarities in the way in which it's kind
of written.

Speaker 5 (01:05:35):
You mean that did infer that the typescript from the
right time.

Speaker 1 (01:05:38):
No, No, not that, I'm talking about how you literally
write the ZOD run schemaema. You used to do the same.
You have this kind of schema definition language that gets
executed at run time, and you kind of had a
similar thing with the now precated React prop types that

(01:06:03):
you used to put on on React class components in
order to specify before we had typescript, we used to
use that to specify the types and it would actually
get checked at run time rather than a bill time,
because there was necessarily an actual bill time to test
it in, but it would only be tested in developer mode,

(01:06:27):
in development mode.

Speaker 6 (01:06:28):
Not in So what's the issue with D you're wondering?

Speaker 1 (01:06:32):
No, First of all, I hope everybody is clear. Ah,
Steve was Ariel's explanation. It seemed to me it was
an excellent explanation. But I was wondering if you have
any questions about that?

Speaker 4 (01:06:45):
Okay, it was excellent.

Speaker 1 (01:06:50):
So basically what it means, though, is that by adding
in ZOD we can do run time type checking. We
can say that what I'm getting over the wire supposed
to have this exact structure. It gets checked at run time.
If it passes, then great. If it fails, we get
an exception.

Speaker 5 (01:07:08):
Excellent, you can handle it. You can choose whether you
raise an exception or I love.

Speaker 6 (01:07:12):
That you use the structure because it's a good segue.

Speaker 4 (01:07:17):
Yeah. So given that problem solved, no.

Speaker 6 (01:07:21):
Yeah, almost, yes or no, kind of It depends which
problems are solved. So here's the thing. Now, let's forget
that the site you do use. Imagine you're using something
like your use case, being like there's a notification system
and you have to update a bunch of stuff related
to like a notification systems or it's like notification type

(01:07:43):
and mode and you know the value of it and whatever,
like an email daily and is it disabled or enable?
Just like a bunch of stuff. That's an object that
flows into the system. Your API on you know, on
this server side uses ODD it says, okay, my notification
schema is is an object that is made up of
notification type, which is supposed to be, like you said,

(01:08:03):
done a structure of a string. So that's fine, that's
a string, and the mode is a string, and everything
else is maybe a string or a poollyon it depends.
So far, so good. And if I try to send
you something like to try to like do type juggling
and send you an array in the notification type so
it's not just email as a string, but you know,
I don't know email and something else as an array,

(01:08:26):
it will get rejected and you think you've kind of
like solved the problem, except there are more sort of
vulnerabilities that can flow in indeed not directly related to ZOD,
but just that using ZOD is potentially a policy that
wouldn't save you from it. So my use case for
that is imagine that now I'm sending in a string,

(01:08:47):
but that string for notification type is underscore underscore proto
underscore underscore. I won't do the whole underscore again, but
just know that when I say proto, that's what I mean.
And my notification mode is going to be a string
also now as adamin identification mode value is going to
be true. Okay, so I'm giving you all of those strings.
ZODD has no issues and it works towards your defined schema.

(01:09:12):
Of all of them have to be strings, so it
flows in. But if all of them you have a
question there no, okay. So if all of them flow
into the app itself and the application does something one
of two things with the data incorrectly in an insecure manner,
then you now have a prototype pollution vulnerability.

Speaker 1 (01:09:32):
Basically, if you're using that field as a key on
an object and you're now accessing that object's prototype instead
of one of the fields on the object.

Speaker 6 (01:09:43):
Correct, that is one, so you could insecurely use it
directly with what is not a literal string. But actually, and.

Speaker 1 (01:09:53):
You know what the lesson is, don't use JavaScript object
as dictionaries.

Speaker 4 (01:09:57):
Use the map instead.

Speaker 6 (01:09:58):
There we go. But there's another way where it can
it can bite you, which is if you don't do that,
but instead you do something like let's say you work
with a nasted data structure. Imagine like address, and then
there's like a business address and office address, and maybe
there's like nested data structures there. And sometimes what people
do is recursive Jason parts the data and set it

(01:10:21):
like that if you do so. Actually, that is the
canonical example of prototype pollution vulnerabilities. So many, many, many,
many libraries, like Lowdash, like object path, like so many
others that's been used like prototype pollution has been found
to be impacting many kinds of vulnerability of libraries in
different ways, but they all basically do the exact same

(01:10:44):
insecure issue, which is an insecure way of doing a
recursive Jason merge. And if you do that and you're
not aware of prototype pollution, then that can crawl in.
And then again, using ZA doesn't help you unless you
do something else, which is using ring literals in ZOD,
but that's not always possible, not always. That data is

(01:11:04):
hardly typed in advance, like type email or type digest.
Maybe your user data is user name or an address
or something like that and you can't confine it to
a literal schema.

Speaker 4 (01:11:16):
Fat.

Speaker 6 (01:11:18):
Oh my god, we did not open that door. That's
a different topic.

Speaker 1 (01:11:22):
The fact the fact that typeescript can you in certain situations,
like everybody goes to evail, but evail is like the
extreme situation. But the fact that even without evil, typescript
can sometimes consider strings as code can introduce certain vulnerabilities

(01:11:42):
because just looking at the type of the thing is
not sufficient, is what you're saying.

Speaker 4 (01:11:47):
Do I understand? Correct?

Speaker 6 (01:11:49):
Correct, It's it's not I mean, yeah, it's not sufficient
because this vulnerability can impact you. And there's another actually
issue with ZOD, so I don't know if you know
you knew this. Another one that's related to a mass
assignment vulnerability that would happen with God is if you
define a schema and let's say my schema is like
my name and my email, and that's what you define

(01:12:12):
and that's what I send in and you do, like
you know, ZOD, you know schema safe parts and all
of this thing, and it doesn't throw it's all success
blah blah blah. You push it down the wire to
your services and repository pattern and you normally do like
you know, user dot save and that user data comes
from the request because you already invalidated it with the schema,
and so that gets persistent on the database. That's a

(01:12:33):
very common pattern also with ORMs. But if I send
another string with the data in the schema, like is
admin or role equals admin, that will also satisfy ZOD
because by default it doesn't have any issue with data
that is not on the schema. So if I add

(01:12:54):
fifty fields and your schema has two fields, your schema
parsing will still say that it's valid. Schema okay, And
that's that the ending.

Speaker 1 (01:13:02):
Of JavaScript objects are open by.

Speaker 6 (01:13:05):
Default because well because you haven't used I mean, the
correct pattern would be to create a new object or
like you said, like map it to a new object
that takes fields one by one that you trust. But
if you just take you know, user equals request by
the user you say I validated it, it's fine. But
then you pass that user from the from their request
which comes from the user input, and pass it all around,

(01:13:26):
you have again that fallacy as if that schema was
checking it and it's valid.

Speaker 5 (01:13:31):
Well you can you can strict par it.

Speaker 1 (01:13:34):
Yeah, it doesn't has the ability to say only these
fields and no more.

Speaker 5 (01:13:39):
I think it does. It's called strict mode. It's strict
parsing and by default. But when ZOE just started it
was actually the other way around. So the default was
too strict parts and obviously it's not that comfortable for
many use cases, so they change the default behavior. But
I think that ran like what we really want to
bring out here for the listeners is that even if

(01:14:01):
you're using ZOD, try to consider understand that if you're
not strict parsing, it could be larger, and that there
is the ability to strict pars it, and we need
to wisely choose it when it's needed.

Speaker 6 (01:14:16):
Exactly, it's just not the default. And when you don't
have defaults, you're going to have adopters who use the
system by the reading or whatever in an insecure way
by default. That's not what you want to do.

Speaker 1 (01:14:27):
And then somebody does Jason stringify or two string or whatever,
and they get something that's different than what they expected.
Correct understood. We're starting to run really short on time.
Is there anything else especially that we want to touch
on that we haven't talked about so far.

Speaker 6 (01:14:45):
We're going to do rejects next time, right, Reel.

Speaker 1 (01:14:48):
I would love to have you on again to talk
about redis everybody's favorite topics.

Speaker 5 (01:14:53):
Recently I've been writing, I've been developing only parsers, so
I've a vote. Like I started off my EXPERI as
a Cobal developer and the Army, and then i moved
to web development, so react and now I'm doing backhand,
so it's pipe and now that's it. I'm a Regicks developer.
Like the next level is pure energy.

Speaker 6 (01:15:14):
Your pyramid right now looking.

Speaker 1 (01:15:18):
Down with all of you lots, you're actually one of
my picks will have to do with parsing, but we'll
get there. So so before we finish and we go
to picks, if anybody wants to get in touch with you,
what would be the best way, especially you are, Reel
as you are have like no presence on the interwebs.

Speaker 5 (01:15:41):
I have LinkedIn.

Speaker 1 (01:15:44):
Oh yeah, everybody's favorite social network, the social net to die.

Speaker 5 (01:15:51):
I'm protecting my soul for now, so no X. Yes,
but you can reach me on LinkedIn and I'm very
polite and I will answer you all.

Speaker 1 (01:16:01):
So it's Aariel Schulman on LinkedIn?

Speaker 4 (01:16:04):
Yes, are you the only? Ariel Shulman on LinkedIn, and I'm.

Speaker 5 (01:16:10):
The how many girls are there with the profile picture
of them on a stage called Aeriel Shulman on LinkedIn.
Let's let's research this thing.

Speaker 1 (01:16:18):
Okay, cool?

Speaker 4 (01:16:20):
Cool.

Speaker 1 (01:16:20):
That's another thing about both of you that your conference speakers,
and that also goes to one of the picks that
I'll have today. But anyway, and how about Julian. If
anybody wants to contact you, what's the best way For.

Speaker 6 (01:16:35):
People outside of Israel? You can just google le Rantel
and you'll find me on x or whatever. Inside Israel,
there is a famous famous Israeli singer called me Randal.
That's not me, it's a very it's it's a very
crude music style here. So I don't know. I won't

(01:16:55):
ope any more than that.

Speaker 1 (01:16:56):
Cool cool, Okay, let's uh, let's move on to pics then, ah,
do you want to start us off with picks?

Speaker 2 (01:17:04):
So I went through the Proxmocks Advanced training with Wihui,
which is the Canadian company that does the training. And
not that I regularly do trainings, but it was the
best training experience that I've ever had. Everything if you've

(01:17:24):
ever done a workshop, you know the first part of
the workshop, because this training had both educational material and
labs and whatnot that like everything just worked. There was
there was no there was nothing that didn't work except
for things that were common user error that were part
of what was going to be covered in the material anyway,

(01:17:47):
and I just thought that that was really really great.
So I am myself working on some proxmox material, which
is why I part of the well. I took the
training primarily to become proxmox certified, but also because I
you know, I wanted to learn, and I wanted the
material that I create to match the same quality that

(01:18:08):
you get from the official training, and hopefully even I'd
like to be on the path to become an official
trainer with Proxmox. But anyway, uh, if you if you
want to have the official Proxmox training, the wee Hui
is probably a better bet from from some of the
things I came to understand then even getting it from

(01:18:30):
Proxmox themselves, just in terms of the way that that
we Hui's business works and how that drove them to
create the course content because there's a lot of leeway
and how to present it. So anyway, and for people
that don't know proxmox is.

Speaker 4 (01:18:47):
It's for co.

Speaker 2 (01:18:48):
Location or for on prem So if you want to
save a ton of money, then you can. You can
use proxmox and have you know, as many nines as
you want up time without without having a cloud bill
that costs you the same amount per month that it
would cost to by the servers out right. And that's
that's all. That's all I got. That's that's my that's

(01:19:10):
that's my thing.

Speaker 1 (01:19:12):
See if I wonder what you want to tell us
talk to us about today in your picks.

Speaker 3 (01:19:18):
Uh, let's see, Well, I suppose we could try something
new like dad jokes.

Speaker 1 (01:19:23):
I love the one about the half brother by the way,
the one that you.

Speaker 3 (01:19:28):
Yeah, that was good for those who aren't familiar with
the one. It's a very short conversation tweening myself and
our friend, and I said, I have a couple, I
have a half brother, and he says different. Mother said,
no shark attacks. But now I'll do some new ones
this week.

Speaker 6 (01:19:46):
The question why.

Speaker 3 (01:19:47):
Shouldn't they dentist marry a manicurist because they'll fight nail
well desert drums? What do you call what do you
call cheese that isn't yours not.

Speaker 5 (01:20:02):
I knew that one.

Speaker 3 (01:20:04):
Yes, well, you should have jumped in and answered it.
I would have taken an answer.

Speaker 2 (01:20:08):
I was on you.

Speaker 4 (01:20:09):
Oh okay.

Speaker 3 (01:20:11):
And then finally, this is just more of an observation
that Bigfoot is sometimes confused with sasquatch, yet he never complains,
you know, yedi y e t I yi. Anyway, those
are the jokes.

Speaker 5 (01:20:23):
You can tell the jokes work because I was like
grasping my hand.

Speaker 3 (01:20:27):
You know, it's more like it's usually the moan and
oh my god, I can't believe he said, Dad, yes, yes,
and when I said it. Sometimes I'll try to work
those in as as you know, real stories, and my
family has gotten wise to it after so many years.
Their first thing out of the mouth, Dad, is this
a joke?

Speaker 6 (01:20:45):
Are you serious?

Speaker 3 (01:20:47):
I just listen, okay, anyway.

Speaker 1 (01:20:50):
Okay, So now it's my turn, and I've not been
on the show for a while. I've I've had various things,
actually a lot of them fun things, but they've kept
me away from the podcast recording. So I've got a
bunch of picks that have accumulated. I'm hoping I'm making
the right choice of using them all now and not

(01:21:11):
saving some for next week, but we'll see. So anyway,
one thing is I was doing this thing. It was
really fun. You reminded me when you were talking about parsing.
We had a certain idiom in again going back to
existing legacy code. We had a certain idiom in the
code which was bad performance wise, and I wanted to

(01:21:37):
fix it. And it was really just, you know, a
very localized rewriting of the code. Now, initially I thought
about using some sort of regular expression and doing a
global search and replaced across the entire project, but that
that kind of turned out to be a bit messy
and kind of what I But I'll get to that.

(01:22:02):
The other thing was that I was worried that, you know,
it fixes the situation as it currently is, but there's
nothing preventing anybody from using that the same poor edium
in the future. So I wanted to safeguard against that
as well. So what I came up with in the
end was a custom EA slint rule with a fixer,
And so I actually had built an E slint rule

(01:22:25):
that analyzed the ASD, identified that kind of localized bad idiom,
and then had the fixer which actually fixed it to
the correct code. And then I basically told the slint
to fix that thing across the entire project, which fixed
all existing occurrences. But now I also had it as

(01:22:47):
a custom rule going forward, so if anybody ever uses
that bad edium in the future, they will get it
reads quickly and they can even you know, right click
and request a fix and it will automatically fix that
code for them. So it's a safeguard. It both fixed
the existing problem and is a safeguard for the future.
And it was a lot of fun to write and
I really enjoyed it. So that was point number one.

(01:23:13):
Point number two, there's a Last year, I actually did
not participate in any conference, which was really depressing in
a way because I'm kind of an extrovert and i
like speaking at conferences. But this year I'm already speaking
at three so I'm really happy about that.

Speaker 5 (01:23:32):
Yay.

Speaker 6 (01:23:33):
Nice.

Speaker 1 (01:23:34):
So so I'll be speaking at the JS Heroes conference
in uh Coclues in Romania. Yeah, it's I think they've
still got tickets. So if you're in Europe and you
want to attend a really top notch JavaScript conference, and
it's top notched despite the fact that I'm speaking there,

(01:23:55):
it's because it's got some amazing speakers on the list.
I highly recommend attending inclusions of Lovely City, although I've
not been, but I've been told I've been to other
parts of Romania they're also lovely. But I've been told
that Clusures Lovely as well. I'm looking forward to it.
So that's conference number one, and then in Tel Aviv,
I'll be speaking both that react next and at No TLV,

(01:24:17):
back to back, day after.

Speaker 5 (01:24:19):
Day, sharing the stage with us two.

Speaker 1 (01:24:22):
Yeah, both of you are speaking at both conferences.

Speaker 5 (01:24:25):
Just one of you this year. Last year I did
never again good luck.

Speaker 1 (01:24:32):
Just so, just so you know that, like a couple
of years back, I gave two talks at the same
conference back to back.

Speaker 4 (01:24:42):
I wasn't.

Speaker 5 (01:24:45):
Isn't it?

Speaker 6 (01:24:45):
That's true?

Speaker 4 (01:24:46):
I yeah, kind of.

Speaker 1 (01:24:48):
But I spoke in one room, finished, wrapped up, went
to another room.

Speaker 4 (01:24:51):
I gave another talk there, changed out. Yeah.

Speaker 1 (01:24:56):
No, anyway, and uh, the other pick that I wanted,
My final pick is a really funny story.

Speaker 4 (01:25:04):
Did you hear that one about in the.

Speaker 1 (01:25:06):
New interview Interview Coder story?

Speaker 4 (01:25:11):
That's so funny?

Speaker 1 (01:25:13):
So yeah, yeah, So basically, these two well ex Columbia students,
they were looking they were.

Speaker 4 (01:25:24):
They were like in the what's it called? They were?

Speaker 1 (01:25:29):
They were like in the They had the mind the
entrepreneur mindset, and they were looking for an application to develop.
So what they created is an application that allows you
to cheat on lead code interviews. It basically, per my understanding,
I've not ever tested it. I'm not interviewing. But anyway,
what it does I understand that it does is that

(01:25:49):
creates an invisible It's a local desktop application that you install.
It creates this kind of invisible window, but but it's
not reflected through Zoom or whatever you're using.

Speaker 4 (01:26:04):
And it shows you answers using AI.

Speaker 1 (01:26:08):
And and it shows you though in a sort of
progressive way, so you kind of it seems like you're
thinking about the answer and coming up with the answer
as it goes along. And it also moves the windows
around so that your eyes aren't always focused on the
same point in the screen, and it does all sorts
of magic. And then they use that program to interview

(01:26:31):
for basically all the fang companies and got offers from
all them. And then they after they got the offers,
they advertised the story and showed the images of all
the offers that they got and apparently somebody from Amazon
got really really upset about it, contact Columbia and had
them expelled.

Speaker 4 (01:26:52):
But I think they're amazing.

Speaker 5 (01:26:54):
Let's hire them now. I think they're jumps.

Speaker 4 (01:26:59):
Yeah, I think they're good for jobs.

Speaker 5 (01:27:01):
Now sounds like overqualified. I would even say.

Speaker 2 (01:27:05):
Yeah, that's that's There was something else like this that
came out a couple of years ago. There was a
United States state government website that put something I mean,
it was ridiculous, like social Security numbers were rendered into
the HTML for It's like they were rendering out their
entire database into the HTML. So when you just search

(01:27:28):
I was doing that way. It was something just absolutely
ridiculously stupid. And then when the person points it out,
then they they you know, trump up these charges of
cybercrime and hacking. It's come on, you know, he right
clicked inspect. So I think that that sounds so overblown

(01:27:49):
from the perspective that they're just pointing out a flaw
in the system. You know, I don't know whether or
not they actually helped people to get the.

Speaker 6 (01:28:00):
Call on browser.

Speaker 1 (01:28:02):
Yeah that's uh. Who likes to use that term a lot,
like Yeah, that incredible tool, the view source and the
browser that incredible hacking tool. By the way, there's the
old story about the person who who uh decoded the
code for DVD coding I think it was, and then

(01:28:25):
some young guy from Norway or or Icelander somewhere, and
they tried to hit him with the DMCA violation or something.
So he basically the way that he got around it
was that he printed the code on the T shirts.

Speaker 4 (01:28:40):
Yeah.

Speaker 1 (01:28:41):
Anyway, by the way, talking about T shirts, somebody might
you might have noticed if you when I got up
that I'm actually wearing the T shirt for a different podcast.
It's the shirt that I got when I was a
guest on JS party. And the reason that I'm wearing
it is because that, unfortunately JAS parties ended. Now you

(01:29:02):
might think that podcasts compete with each other. No, I
think it's certainly a case of rising tie lifts all ship.
I'm really saddened whenever something like whenever a podcast just stops.
I know that change log now has like general podcasts,
but the fact that they had a dedicated JavaScript podcast
was great. I enjoyed listening to it. As I said,

(01:29:24):
I was a guest on it. I'm sadden that it ended,
and I'm happy that we're continuing, so you know, if
you're looking for your JavaScript fix, then stay with us.
And those would be my picks. Reel Iran who wants
to go Firstran goes first.

Speaker 4 (01:29:42):
You don't have to.

Speaker 1 (01:29:46):
You don't have to give picks. It's it's it's a nice.

Speaker 5 (01:29:53):
I'm not ruining my reputation.

Speaker 6 (01:29:54):
Then I'll go quick on them.

Speaker 4 (01:29:56):
Though.

Speaker 6 (01:29:57):
TV shows, I'll go for Arcane and Blue Eye Samurai,
which are masterpieces. You have to watch them if you're
into and if even if you're not into like anime
and stuff like that, they're like amazing.

Speaker 4 (01:30:10):
They're not exactly animated though.

Speaker 6 (01:30:12):
Not exactly animate though, but it's also not like live
action and stuff, so I highly recommend watching them. Arcane
specifically has an incredible soundtrack which is very emotional. It's
it's yeah yeah. Video game book wise, I'll go with
sand Worm by Andy Green. If you like the kind

(01:30:35):
of like how cyber security kind of like started, you know,
all the things like you know, Russian hacking groups and
stuff like that, everything that started in Ukraine like over
a decade ago. It's super cool. It goes and analysis
like why in the politics and how security researchers go
at it incidents and stuff like that podcast go with Starduk.

(01:30:57):
I love like space and astronomy and stuff like that,
and it has niled the grass dison and it's like
a super fun space and time and everything around this
physics stuff is super fun to watch events. Sorry to
listen if you go to events and you like that.
I'm actually going to recommend everyone here who are developers

(01:31:18):
to go to def Con, which is super weird hacker
kind of like underground punk style hacking conference in Vegas
in the summer in August. You'll get a definitely a
good taste of what the culture is like.

Speaker 4 (01:31:33):
Would you also get hacked while you're there?

Speaker 6 (01:31:36):
So for a long time actually that was a thing
where you would be recommended to go without any mobile
devices or mobile devices turned off, never connect to any
Wi Fi whatever you think that is, mobile devices off,
louted off everything else. Wow, But yeah, it had that
reputation for a long time, definitely since like the early days,
like like nineties and stuff like that. But it's far

(01:32:00):
more mature now like that it's people like, don't do
those things anymore. And I mean, if you do care
about your privacy and devices anyway, don't culture with your
phone and laptop and just work off those are my.

Speaker 5 (01:32:15):
Picks greatly, like all of the above.

Speaker 4 (01:32:20):
No problem.

Speaker 1 (01:32:21):
Just having you here is good enough. Okay then, everybody,
thank you for participating on our show. Steve had to
drop off, but you know we are still here and
hopefully so are you. So thank you all, Thank you Ariel,
thank you Leroan, and see you all next time.

Speaker 5 (01:32:38):
Thank you for having us

All Episodes

TypeScript, Security, and Type Juggling with Ariel Shulman & Liran Tal - JSJ 679

Episode Transcript

Popular Podcasts

Dateline NBC

Stuff You Should Know

Law & Order: Criminal Justice System - Season 1 & Season 2

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}TypeScript, Security, and Type Juggling with Ariel Shulman & Liran Tal - JSJ 679