You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: public/blogs/csrf-mitigation.mdx
+13-4Lines changed: 13 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -34,7 +34,7 @@ Since the `Origin` header is being added automatically by browsers as part of th
34
34
<H3>"Sec-Fetc-" Headers</H3>
35
35
36
36
<C>
37
-
Fetch Metadata headers, [introduced]()in 2019 to provide additional context about the resource request. But all you have to know for now is you can use it to to check the origin
37
+
Fetch Metadata headers, [introduced]()last year to provide additional context about the resource request. But all you have to know for now is you can use it to to check the origin
On the server side, when handling incoming requests, the server decodes or decrypts the JWT or JWE to extract the UUID. Simultaneously, it decodes the HMAC-CSRF token, verifies its integrity using the stored secret key, if the integrity was not preserved, the server logs, and blocks, else it extracts the UUID. If the extracted UUIDs do not match, there is a potential indication of tampering or unauthorized access, the server logs, and blocks.
137
+
On the server side, when handling incoming requests, the server decodes or decrypts the JWT or JWE to extract the UUID. Simultaneously, it decodes the HMAC-CSRF token and verifies its integrity using the stored secret key. If the integrity check fails, the server logs the event and blocks the request. If the integrity is preserved, the server extracts the UUID from the token.
138
+
</C>
139
+
<C>
140
+
If the UUIDs extracted from the JWT/JWE and the HMAC-CSRF token do not match, it may indicate tampering or unauthorized access. In this case, the server logs the event and blocks the request.
141
+
</C>
142
+
<C>
143
+
You might ask why not block immediately. The reason is that understanding the type of attack is crucial. By verifying the integrity of the tokens first, you can determine what the attacker attempted to do. If the cookie exists but its integrity is compromised, it suggests the attacker managed to swap the JWT cookie but couldn't sign it with the secret key.
144
+
A worse scenario is if the attacker already knows the secret key but is unaware of the random that's supposed to exist in both the CSRF token and the JWT/JWE. This information is vital for understanding the extent of the breach and implementing appropriate countermeasures.
138
145
</C>
139
146
140
147
<H3>Stateful Services</H3>
@@ -201,9 +208,11 @@ Here's an AJAX example
201
208
var csrfToken = 'CSRF_TOKEN' // use a template engine,
202
209
// or whatever framework you're using
203
210
// to render this value.
211
+
204
212
// div element to hold the hidden token
205
213
var csrfDiv = document.createElement('div');
206
214
csrfDiv.id = 'csrfTokenDiv';
215
+
207
216
// hidden input field and set its value to the generated CSRF token
208
217
var input = document.createElement('input');
209
218
input.type = 'hidden';
@@ -238,7 +247,7 @@ If you want to see a framework implementation of the synchronized pattern , chec
238
247
</C>
239
248
<H2>Cookies</H2>
240
249
<C>
241
-
Avoid setting cookies with a specific domain to minimize security risks. When a cookie is domain-specific, all subdomains share that cookie, which can pose risks if you get hit with a <Lhref="https://developer.mozilla.org/en-US/docs/Web/Security/Subdomain_takeovers">subdomain takeover</L> attack.
250
+
Avoid setting cookies with a specific domain to minimize security risks. When a cookie is domain-specific, all subdomains share that cookie, which can pose risks if you get hit with a <Lhref="https://developer.mozilla.org/en-US/docs/Web/Security/Subdomain_takeovers">subdomain takeover.</L>
242
251
</C><C>
243
252
For session cookies, ensure they are protected by:
244
253
</C><C>
@@ -272,7 +281,7 @@ Read about [`Lax`]() and [`Strict`]() from the official [RFC](). Here's is basic
272
281
<C>
273
282
**``Strict``:** This value prevents cookies from being sent in all cross-site browsing contexts, including regular links. For example: You're logged in your banking account, which means you have a session cookie. If this banking website employs the Strict ``SameSite`` value for its session cookies, and you click on a link to perform a banking transaction from an external website (like a forum or email) say https://scam-me-please.com , the banking website won't receive the session cookie due to the ``Strict`` setting. Consequently, the user won't be able to complete the transaction because the session information is not sent with the request.
274
283
</C><C>
275
-
**``Lax``:** The default value of ``SameSite`` is Lax ( since Chrome version 80, in February 2020) , which provides a balance between security and usability. Cookies are allowed when following regular links from external sites but are blocked in CSRF-prone requests such as POST methods. Only cross-site requests that are considered safe (like top-level navigations) are allowed in Lax mode.
284
+
**``Lax``:** The default value of ``SameSite`` is Lax ( since Chrome version 80, February this year) , which provides a balance between security and usability. Cookies are allowed when following regular links from external sites but are blocked in CSRF-prone requests such as POST methods. Only cross-site requests that are considered safe (like top-level navigations) are allowed in Lax mode.
276
285
</C><C>
277
286
**``None``:** Using the ``None`` value means the cookie is sent with all cross-site requests, which can potentially expose users to CSRF attacks. Simply don't use this.
Copy file name to clipboardExpand all lines: public/blogs/fundamentals.mdx
+8-8Lines changed: 8 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,7 +16,7 @@ tags:
16
16
17
17
<C>
18
18
This blog post was inspired by a recent conversation with a friend who had completed yet another ripoff JavaScript bootcamp. When they asked me whether they should start with
19
-
<Lhref="https://spring.io/projects/spring-boot">Spring</L>, <Lhref="https://www.djangoproject.com/">Django</L>, or <Lhref="https://expressjs.com/">Express</L>, I got confused. The question seemed misguided, I first thought about redirecting their focus towards a foundational understanding of <Lhref="https://datatracker.ietf.org/doc/html/rfc2616">HTTP</L> and grasp the protocol's essence first,thinely. But then I soon realized the broader issue at hand: the misconception that learning involves a linear progression of hopping from one tool to another, across different languages and ecosystems.
19
+
<Lhref="https://spring.io/projects/spring-boot">Spring</L>, <Lhref="https://www.djangoproject.com/">Django</L>, or <Lhref="https://expressjs.com/">Express</L>, I got confused. The question seemed misguided, I first thought about redirecting their focus towards a foundational understanding of <Lhref="https://datatracker.ietf.org/doc/html/rfc2616">HTTP</L> and grasp the protocol's essence first. But then I soon realized the broader issue at hand, which is the misconception that learning involves a linear progression of hopping from one tool to another, across different languages and ecosystems.
20
20
<S/>
21
21
It became apparent that my friend's inquiry about different frameworks operating on totally different languages and ecosystems, neither of which they were even proficient in, reflected a common misunderstanding.
22
22
My advice was: focus on learning more fundamentals. Better yet, grasp how computers operate. So I ended up sending them a copy of "The C Programming Language" book and advised them to start there. Reflecting on this, I realized my advice was somewhat selfish, as I didn't want to lecture for 30 minutes about the importance of fundamentals and where to even begin.
@@ -49,13 +49,13 @@ The question is, how do I learn or where do I even look ? The answer is simple:
49
49
50
50
<H2>Stop Getting Duped By Dream Sellers</H2>
51
51
<C>
52
-
Stop falling prey to the false promises peddled by individuals and institutions eager to take your money by selling you unrealistic dreams. Just as you can't expect to achieve six-pack abs and bulging biceps in four weeks with a magical training program advertised by some juiced up guy on Instagram when you haven't stepped inside a gym for a day in your life, you shouldn't expect to become a "full-stack" developer in 3 months through bootcamps.
52
+
Stop falling prey to the false promises peddled by individuals and institutions eager to take your money by selling you unrealistic dreams. Just as you can't expect to achieve six-pack abs and bulging biceps in four weeks with a magical training program advertised by some juiced up guy on Instagram when you haven't stepped in the gym for a day in your life, you shouldn't expect to become a "full-stack" developer in 3 months through bootcamps.
53
53
</C>
54
54
<C>
55
55
So let me say this: Connecting some JavaScript CRUD APIs together does not make you a "full-stack" developer, no one on earth is full stack, you cannot be at all places at once, you cannot be an expert at literally everything at once **ESPECIALLY AFTER 3 MONTHS!**
56
56
</C>
57
57
<C>
58
-
Let me reiterate: connecting some JavaScript CRUD APIs together does not make you a full-stack developer, it only means you've memorized some broken English to create another useless todo app (at least be creative). These advertised programs always **overpromise** and **underdeliver**, setting unrealistic expectations and leaving many aspiring developers disillusioned and frustrated and definitely not ready to deliver in the market, well a marked that is drowning in mediocre talent anyway.
58
+
Let me reiterate: connecting some JavaScript CRUD APIs together does not make you a full-stack developer, it only means you've memorized some broken English to create another useless todo app (at least be creative). These advertised programs always **overpromise** and **underdeliver**, setting unrealistic expectations and leaving many aspiring developers disillusioned and frustrated and definitely not ready to deliver in the market, well a marked that is drowning in <Lhref="/blog/tag/skill-issues">mediocre</L> talent anyway.
59
59
</C>
60
60
61
61
<C>
@@ -69,8 +69,8 @@ When you focus on mastering the core concepts, you're building a strong foundati
69
69
It's the same as driving. Sure, you can learn to drive in a couple of weeks and pass the exam, but true proficiency goes beyond memorizing the sequence of which 3D objects have to move in a 3D plane in order to make a vehicle take you from point A to point B.
70
70
</C>
71
71
<C>
72
-
What I mean by that is: sure, you can learn React in 3 months too, but did you learn it? or memorize it? Did you learn programming or have memorized some language specific APIs? In my opinion before you can use a tool, you should be able to build a prototype of it, understand how it works under the hood. Trying to use React? Build a rudimentary version of it. Trying to use an <Lhref="https://en.wikipedia.org/wiki/Object%E2%80%93relational_mapping">ORM</L>? Build one. What about trying to use the new trending web framework which literally does the same thing all the other ones do? Build it. Blast some <Lhref="https://datatracker.ietf.org/doc/html/rfc9293">TCP</L> connections until you have something.
73
-
All I'm trying to say is that technologies come and go, your favorite blazingly fast, easy to implement, easy to learn framework comes and goes. You don't have to know such and such library to be an expert, that thing is ephemeral, if it disappears or goes out of fashion, there goes you expertise with it, congrats! you've wasted your time.
72
+
What I mean by that is, sure, you can learn React in 3 months too, but did you learn it? or memorize it? Did you learn programming or have memorized some language specific APIs? In my opinion before you can use a tool, you should be able to build a prototype of it, understand how it works under the hood. Trying to use React? Build a rudimentary version of it. Trying to use an <Lhref="https://en.wikipedia.org/wiki/Object%E2%80%93relational_mapping">ORM</L>? Build one. What about trying to use the new trending web framework which literally does the same thing all the other ones do? Build it. Blast some raw <Lhref="https://datatracker.ietf.org/doc/html/rfc9293">TCP</L> until you have something.
73
+
All I'm trying to say is that technologies come and go, your favorite blazingly fast, easy to implement, easy to learn framework comes and goes, it's literally an implementation of the same <Lhref="https://en.wikipedia.org/wiki/Request_for_Comments">RFC</L> made with different programming languages. You don't have to know such and such library to be an expert, that thing is ephemeral, if it disappears or goes out of fashion, there goes you expertise with it, congrats! you've wasted your time.
74
74
</C>
75
75
<C>
76
76
Understand that true engineering means going beyond memorization and instead comprehending the fundamental principles that govern a system. It's about understanding the "why" behind things, which in turn makes you more versatile and effective problem solver.
@@ -83,7 +83,7 @@ When you start asking "why", you'll gradually connect the pieces together, start
83
83
I can't precisely outline a <Lhref="https://roadmap.sh">roadmap</L> for you because the field is vast. If I lay out a plan, you might quickly lose interest, feeling overwhelmed by its enormity, you might even focus more on unnecessary topics while leaving more important ones without much attention, because all of these concepts I'll be mentioning will sound like a foreign language to you. Instead, I'll suggest an approach:
84
84
</C>
85
85
<C>
86
-
Just pick a thing, complex or simple, anywhere then keep asking why does this thing exist? What problem is it trying to solve? and follow the trail. By doing so, you'll find yourself going deep into the <Lhref="https://youtu.be/zE7PKRjrid4?si=24T8DoioD-7WotOC&t=93">rabbit hole</L>. It is an intricate journey, but after such a deep dive, you'll find yourself surpassing 99% of individuals out there who don't ask questions and don't even put in any effort at all, just accepting the information as is, and that goes out for everything not just software engineering.
86
+
Just pick a thing, complex or simple, anywhere that you think might be interesting, then keep asking why does this thing exist? What problem is it trying to solve? and follow the trail. By doing so, you'll find yourself going deep into the <Lhref="https://youtu.be/zE7PKRjrid4?si=24T8DoioD-7WotOC&t=93">rabbit hole</L>. It is an intricate journey, but after such a deep dive, you'll find yourself surpassing 99% of individuals out there who don't ask questions and don't even put in any effort at all, just accepting the information as is, and that goes out for everything not just software engineering.
87
87
</C>
88
88
<H2>Here Are Some Tips</H2>
89
89
<C>
@@ -107,14 +107,14 @@ Draw inspiration from the code you read and aim for projects that challenge and
107
107
</C>
108
108
109
109
<C>
110
-
Always consult official documentations and RFCs when learning a new technology, language, or anything in life really. Like the topic of health, read the official studies instead of relying on some guy on social media yapping about "studies show that...". **WHAT STUDIES? LEMME SEE THEM!**
110
+
Always consult official documentations and RFCs when learning a new technology, language, or anything in life really. Like the topic of health, read the official studies instead of relying on some guy on social media <Lhref="https://www.urbandictionary.com/define.php?term=Yapping">yapping</L> about "studies show that...". **WHAT STUDIES? LEMME SEE THEM!**
111
111
<S/>
112
112
If the documentation is inadequate, resort to reading the source code and try to connect the dots. Never rely on secondhand information. Your brain may trick you into seeking the easiest path to preserve the most amount of energy, like watching a video or purchasing courses (though the vast majority are a ripoff, some can be time-savers). Distilled secondhand information can lead astray, not even mentioning mis/disinformation.
113
113
<S/>
114
114
Instead, your brain should engage, think, and exert effort to understand, if it's dormant you're slacking big time.
115
115
</C>
116
116
<C>
117
-
Start using Linux instead of you normie operating system, you can search <Lhref="https://duckduckgo.com/?va=i&t=hd&q=why+use+linux+over&ia=web">why</L>.
117
+
Start using Linux instead of you normie operating system, you can search <Lhref="https://duckduckgo.com/?va=i&t=hd&q=man+windows+is+shit&ia=web">why</L>.
118
118
</C>
119
119
<C>
120
120
Be an engineer not a <Lhref="https://johndanielraines.medium.com/be-an-engineer-not-a-frameworker-c58fe28d0c88">frameworker</L>, so think like one.
Copy file name to clipboardExpand all lines: public/blogs/micro-management.mdx
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,6 +27,6 @@ difficulty keeping your team [motivated](), delegating [tasks](), fixation on sm
27
27
</C>
28
28
<H2>Symptoms</H2>
29
29
<C>
30
-
As a good manager, you should establish **clear** quality **standards**, define *roles*, **responsibilities** and **expectations**, and outline the **rewards** for success and consequences for failure. A good manager doesn't need to micromanage people, instead, they periodically lay down **firm** guidelines: deliver results and be **rewarded**, fail to meet expectations and face **consequences**, it's a straightforward principle that has stood the test of time.
30
+
As a good manager, you should establish **clear** quality **standards**, define *roles*, **responsibilities** and **expectations**, and outline the **rewards** for success and consequences for failure. A good manager doesn't need to micromanage people, instead, they periodically lay down **firm** guidelines: deliver results and be **rewarded**, fail to meet expectations and face **consequences**, it's a straightforward principle that has stood the test of time. So use it.
0 commit comments