Chapters

43 Chapters | 5:00:38 |

01

The World of React + ESLint

8:13
02

React.createElement()

6:40
03

JSX

6:27
04

React Components

8:50
05

Props

6:40
06

Collection & Rendering a Table

6:28
07

The key Prop & Inline Rendering

4:38
08

Build the Static App First

8:05
09

State: For Magic Updating Good Times

8:32
10

Handling Events (like onClick)!

4:41
11

Child Component

8:35
12

Notifying Parent Components: Callback Props

5:24
13

Smart vs Dumb Components

8:48
14

Prop Validation: PropTypes

6:40
15

Removing propTypes on Production

3:01
16

Moving the Rep Logs to State

5:01
17

Smart Components & Spread Attributes

6:06
18

Handling a Form Submit

8:24
19

New Component to Hold our Form

8:25
20

Refs

9:36
21

Immutability / Don't Mutate my State!

8:34
22

Dumb Components with State

4:53
23

Form Validation State

5:12
24

Controlled Form Input

9:20
25

Controlled Component Form

9:17
26

Deleting Items

6:15
27

API Setup & AJAX with fetch()

7:14
28

API Auth & State via AJAX

7:33
29

Loading Messages

3:38
30

Hitting the DELETE Endpoint

6:37
31

The POST Create API

9:04
32

Polyfills: fetch & Promise

5:19
33

Success Messages + The Style Attribute

6:27
34

Temporary Messages & componentWillUnmount

6:14
35

Updating Deep State Data

7:12
36

Server Validation & fetch Failing

5:59
37

Displaying Server Validation Errors

7:40
38

...Object Rest Spread

6:40
39

Passing Data from your Server to React

7:11
40

Passing Server Data to React Props

8:45
41

Reusable Components

9:14
42

CSRF Protection Part 1

5:25
43

CSRF Protection Part 2

7:39

This course is archived!

While the concepts of this course are still largely applicable, it's built using an older version of Symfony (4) and React (16).

> JavaScript Frameworks & Tools > React with Symfony

Buy Access to Course

42.

CSRF Protection Part 1

|

Autoplay

Keep on Learning!

If you liked what you've learned so far, dive in! Subscribe to get
access to this tutorial plus video, code and script downloads.

Start your All-Access Pass

Buy just this tutorial for $12.00

Previous Chapter

Next Chapter

With a Subscription, click any sentence in the script to jump to that part of the video!

Login Subscribe

Login or register to check out the script

6 Comments

Sort By

Login or Register to join the conversation

Mouad E. 6 years ago

Hi weaverryan am sending a post request from a react app to a sf4 api app, should i delete $event->isMasterRequest() because an option request comes before my post request and sf treated it as a sub request and return 405 error, what should i do?

|

weaverryan SFCASTS Mouad E. 6 years ago

Hey @adam!

Hmm.

> because an option request comes before my post request and sf treated it as a sub request

This should *not* be the case. Both requests - the POST and the HEAD - are *real* requests into your app and are both *master* requests. I'm 100% sure about that :). So if you're seeing that the HEAD is a sub-request, it must mean that while handling the HEAD "master" request, something else internally is making a sub-request. Basically, my point is: look a bit harder and what's going on... because something isn't right :).

Btw, that HEAD request is likely for CORS. Are you using something like NelmioCorsBundle to return the CORS headers? If so, *it* should be the thing that is responsible for returning the correct response (instead of allowing it to hit your controller, which will return a 405 if it's only set up to respond to POST requests).

Cheers!

|

Anthony R. 7 years ago

Hi Ryan,

I hope you’re excellent, it’s been a long time.

We need to be careful here because I feel the information mentioned here is misguiding:

> First, disallow AJAX requests from all domains except for your domain. Actually, this is just how the Internet works: you can't make AJAX requests across domains.

It seems you are referring to the same-origin policy. However SOP is designed to prevent websites from reading credentialed responses from a third party but not to prevent from posting data. It is possible to mutate state on another website via XHRs without any problem, SOP only makes it impossible to read the response. Yes, we can make cross domain XHR requests, we are just not allowed to read responses (depending on the CORS policy in place). It is also possible to make that XHR credentialed using ‘withCredentials: true’.
So here, with current tuto in place, we are subject to CSRF attacks.

> This is the second rule for CSRF protection: only allow data to be sent to your server as JSON.

The way data is represented is nothing to do with CSRF protection - using json does not protect users further. The risk here comes from the session-based authentication. An authenticated POST is an authenticated POST.. the way the data is represented is irrelevant for a CSRF defense.

Protecting SPA against CSRF and XSS attacks is not easy, but here I believe both points would misguide users in thinking they are protected when they would not be.

Just a heads up!

P.S. I think it would be helpful to a lot of people if you covered a safe login authentication for an SPA which would be immune to CSRF login attacks, this is not easy to do, whether one uses session based authentication OR token based authentication.

|

weaverryan SFCASTS Anthony R. 7 years ago edited

Hey Anthony R. !

Just an update on this. Someone else pointed out that these protections ay in fact *not* be enough as browsers have introeduced a feature (https://github.com/pillarjs... that indeed may allow application/json requests to be sent across JavaScript without preflight :/. And more broadly, browsers seem to think that relying on this is not sufficient. We're adding a note about this, and so, indeed, using CSRF tokens is best. We show how in this tutorial and there is also the wonderful bundle you linked to: https://github.com/dunglas/...

Cheers!

|

weaverryan SFCASTS Anthony R. 7 years ago edited

Hey Anthony R.!

Thanks for the post - seriously :). This was a tough chapter because it's security-related and I wanted to get it right. Now, I really want to make sure that I've got it right, with your help. So, I have a few questions:

However SOP is designed to prevent websites from reading credentialed responses from a third party but not to prevent from posting data. It is possible to mutate state on another website via XHRs without any problem

How? I mean, I know one way: via form posts, which could be on the bad domain with an action=http://thegoodomain.example or even with the good domain form hidden in an iframe on the bad domain. But, there is no other way to make a request via XHR, or JSONP (other than a GET request) to another domain, unless that domain has allowed it via CORS, right?

The way data is represented is nothing to do with CSRF protection - using json does not protect users further. The risk here comes from the session-based authentication. An authenticated POST is an authenticated POST.. the way the data is represented is irrelevant for a CSRF defense.

Actually, that's not entirely true :). As I mentioned above, there IS certainly an attack vector to make a POST request to another domain using a traditional HTML. But, HTML forms always submit with Content-Type: application/x-www-form-urlencoded or Content-Type: multipart/form-data. There is no way for the "bad" domain to add a form to their site and change this fact. So, if our API always checks for the Content-Type to be application/json (or really, anything other than the 2 that could be sent by a form), then it eliminates the CSRF attack from an embedded form.

Let me know what you think or what I'm not thinking about. From my perspective, the protection is a combination of (A) disallowing cross-domain via XHR... which only leaves GET requests and POST requests initiated by a form. And then (B) checking always for application/json Content-Type, which eliminates the form request. The only thing remaining are GET requests from other domains, which is safe because the attacker can't read the response (assuming, of course, that you haven't done something crazy and "mutated" your server on a GET request). Here's a source I was referencing for this section: https://github.com/pillarjs/understanding-csrf

Cheers!

|

Anthony R. weaverryan 7 years ago

Hi Ryan,

I have now re-read your post as well as your answer.

> From my perspective, the protection is a combination of (A) disallowing cross-domain via XHR... which only leaves GET requests and POST requests initiated by a form. AND then (B) checking always for application/json Content-Type, which eliminates the form request.

Yes, yes and yes, not sure what was happening inside my head. I forgot preflight requests would fire on cross-origin POST request WHEN Content-Type is 'application/json' (more precisely when it is NOT one of application/x-www-form-urlencoded, multipart/form-data, or text/plain). I totally forgot about preflight... thank you!

So, yes, everything makes a lot of sense... apologies for the confusion and thank you so much for being so awesome.

Based on my very first point, I would still rephrase the following:

> First, disallow AJAX requests from all domains except for your domain. Actually, this is just how the Internet works: you can't make AJAX requests across domains.

into the following:

--> First, disallow AJAX requests from all domains except for your domain. Actually, this is just how the Internet works: you can't make AJAX requests across domains WHEN CONTENT-TYPE IS NOT ONE OF application/x-www-form-urlencoded, multipart/form-data, or text/plain.

Because, technically, it is possible to send cross-origin POST XHR requests with any of these 3 content-types and even if you can't read the response, you can mutate state. I.e. there is no preflight for these as they are Simple Requests:
https://developer.mozilla.o...

P.S. For those that would still would want to submit via `application/x-www-form-urlencoded`, I found the DunglasAngularCsrfBundle after some digging!
https://github.com/dunglas/...

|

While the concepts of this course are still largely applicable, it's built using an older version of Symfony (4) and React (16).

Symfony 4 React 16

What PHP libraries does this tutorial use?

// composer.json
{
    "require": {
        "php": "^7.2.0",
        "ext-iconv": "*",
        "composer/package-versions-deprecated": "^1.11", // 1.11.99
        "doctrine/annotations": "^1.0", // v1.8.0
        "doctrine/doctrine-bundle": "^1.6", // 1.9.1
        "doctrine/doctrine-cache-bundle": "^1.2", // 1.3.3
        "doctrine/doctrine-fixtures-bundle": "~3.0", // 3.0.2
        "doctrine/doctrine-migrations-bundle": "^1.2", // v1.3.1
        "doctrine/orm": "^2.5", // v2.7.2
        "friendsofsymfony/jsrouting-bundle": "^2.2", // 2.2.0
        "friendsofsymfony/user-bundle": "dev-master#4125505ba6eba82ddf944378a3d636081c06da0c", // dev-master
        "phpdocumentor/reflection-docblock": "^3.0|^4.0", // 4.3.0
        "sensio/framework-extra-bundle": "^5.1", // v5.2.0
        "symfony/asset": "^4.0", // v4.1.4
        "symfony/cache": "^3.3|^4.0", // v4.1.4
        "symfony/console": "^4.0", // v4.1.4
        "symfony/flex": "^1.0", // v1.21.6
        "symfony/form": "^4.0", // v4.1.4
        "symfony/framework-bundle": "^4.0", // v4.1.4
        "symfony/lts": "^4@dev", // dev-master
        "symfony/monolog-bundle": "^3.1", // v3.3.0
        "symfony/polyfill-apcu": "^1.0", // v1.9.0
        "symfony/property-access": "^3.3|^4.0", // v4.1.4
        "symfony/property-info": "^3.3|^4.0", // v4.1.4
        "symfony/serializer": "^3.3|^4.0", // v4.1.4
        "symfony/swiftmailer-bundle": "^3.1", // v3.2.3
        "symfony/twig-bundle": "^4.0", // v4.1.4
        "symfony/validator": "^4.0", // v4.1.4
        "symfony/yaml": "^4.0", // v4.1.4
        "twig/twig": "2.10.*" // v2.10.0
    },
    "require-dev": {
        "easycorp/easy-log-handler": "^1.0.7", // v1.0.7
        "symfony/debug-bundle": "^3.3|^4.0", // v4.1.4
        "symfony/dotenv": "^4.0", // v4.1.4
        "symfony/maker-bundle": "^1.5", // v1.5.0
        "symfony/phpunit-bridge": "^4.0", // v4.1.4
        "symfony/stopwatch": "^3.3|^4.0", // v4.1.4
        "symfony/var-dumper": "^3.3|^4.0", // v4.1.4
        "symfony/web-profiler-bundle": "^3.3|^4.0", // v4.1.4
        "symfony/web-server-bundle": "^4.0" // v4.1.4
    }
}

What JavaScript libraries does this tutorial use?

// package.json
{
    "dependencies": {
        "@babel/plugin-proposal-object-rest-spread": "^7.12.1" // 7.12.1
    },
    "devDependencies": {
        "@babel/preset-react": "^7.0.0", // 7.12.5
        "@symfony/webpack-encore": "^0.26.0", // 0.26.0
        "babel-plugin-transform-object-rest-spread": "^6.26.0", // 6.26.0
        "babel-plugin-transform-react-remove-prop-types": "^0.4.13", // 0.4.13
        "bootstrap": "3", // 3.3.7
        "copy-webpack-plugin": "^4.4.1", // 4.5.1
        "core-js": "2", // 1.2.7
        "eslint": "^4.19.1", // 4.19.1
        "eslint-plugin-react": "^7.8.2", // 7.8.2
        "font-awesome": "4", // 4.7.0
        "jquery": "^3.3.1", // 3.3.1
        "promise-polyfill": "^8.0.0", // 8.0.0
        "prop-types": "^15.6.1", // 15.6.1
        "react": "^16.3.2", // 16.4.0
        "react-dom": "^16.3.2", // 16.4.0
        "sass": "^1.29.0", // 1.29.0
        "sass-loader": "^7.0.0", // 7.3.1
        "sweetalert2": "^7.11.0", // 7.22.0
        "uuid": "^3.2.1", // 3.4.0
        "webpack-notifier": "^1.5.1", // 1.6.0
        "whatwg-fetch": "^2.0.4" // 2.0.4
    }
}

Previous Chapter

Next Chapter