csr-rsc-ssg-isr-ssr-ssrf

Questa repo può servire da supporto per presentare uno o più meetup. Il percorso è il seguente...

"CSR" Client Side Rendering: React come libreria SPA standard
"RSC" React Server Components: esecuzione di componenti React solo lato server
"SSG" Static Site Generation: esecuzione di componenti React durante la build
"ISR" Incremental Static Regeneration: rigenerazione di componenti su richiesta
"SSR" Server Side Rendering: pre-rendering lato server ed esecuzione (hydration) lato client
"SSRF" Server Side Request Forgery: una vulnerabilità di sicurezza corretta di recente in Next.JS

Questo lavoro si basa principalmente su due fonti:

mappa mentale

CSR Client Side Rendering

`1-csr-load-data` vanilla react SPA caricamento dati

mappa mentale CSR

[!IMPORTANT] CSR (Client-Side Rendering): il codice React viene consegnato al browser, che genera contenuti inseriti nel DOM.

client side rendering caricamento dati

demo

cd 1-csr-load-data
npm start

gif caricamento dati CSR

`2-csr-router` vanilla react SPA routing

[!IMPORTANT] Dopo il primo caricamento della pagina, la navigazione verso altre pagine dello stesso sito utilizza JavaScript per ri-renderizzare parti della pagina senza richiedere un aggiornamento completo della pagina.

demo

cd 2-csr-router
npm start

routing client side rendering

RSC React Server Components

`3-rsc-load-data` React Server Components (implementazione Next.js) caricamento dati

mappa mentale CSR

[!IMPORTANT] Componenti React scritti per essere eseguiti solo sul server, piuttosto che nel browser.

React Server Components caricamento dati

demo

cd 3-rsc-load-data
npm run build
npm run start

routing client side rendering

`4-rsc-router` React Server Components (implementazione Next.js) routing

mappa mentale CSR

[!IMPORTANT] I componenti vengono eseguiti solo sul server. Il comportamento predefinito è il rendering statico: i componenti vengono eseguiti in fase di build.

demo

cd 4-rsc-router
npm run build
npm run start

routing React server components

`5-SSR` SSR Server Side Rendering

mappa mentale SSR

[!IMPORTANT] SSR significa prerenderizzare i componenti client sul server. Il codice React viene eseguito nel momento in cui viene richiesto. Il risultato può essere memorizzato nella cache per richieste future.

Buona pratica: definire i componenti 'use client'; il più in basso possibile nell'albero dei componenti.

https://nextjs.org/docs/app/building-your-application/rendering/composition-patterns#moving-client-components-down-the-tree

Hydration

[!IMPORTANT] "In React, “hydration” è il modo in cui React si “aggancia” all'HTML esistente che è già stato renderizzato da React in un ambiente server. Durante l'hydration, React tenterà di collegare i listener di eventi al markup esistente e di subentrare nel rendering dell'app sul client. Nelle app completamente costruite con React, di solito si idrata una sola “root”, una volta all'avvio dell'intera app."

https://react.dev/reference/react-dom/client/hydrateRoot

https://www.gatsbyjs.com/docs/conceptual/partial-hydration/

demo

cd 5-ssr
npm run build
npm run start

SSR

`6-pages-router-ssg` (implementazione Next.js)

mappa mentale page router SSG

[!IMPORTANT] SSG (Static Site Generation) con il pages router: il codice React viene eseguito quando compili l'applicazione e l'output generato è statico.

demo

cd 6-pages-router-ssg
npm run build
npm run start

`7-pages-router-isr` (implementazione Next.js)

mappa mentale page router ISR

[!IMPORTANT] ISR (con il pages router): "Next.js ti consente di creare o aggiornare pagine statiche dopo aver creato il tuo sito. L'Incremental Static Regeneration (ISR) ti permette di usare la generazione statica in base alla singola pagina, senza dover ricostruire l'intero sito. Con l'ISR puoi mantenere i vantaggi della staticità scalando fino a milioni di pagine."

demo

cd 7-pages-router-isr
npm run build
npm run start

Perché ISR?

"i dati potrebbero diventare obsoleti al momento della richiesta"

https://vercel.com/blog/nextjs-server-side-rendering-vs-static-generation

Server actions

https://react.dev/reference/rsc/server-actions

SSRF (corretta in NextJS v14.1.1)

Definizione di SSRF

...

Perché?

Se si ha accesso a un server vulnerabile ma non al server di destinazione direttamente (DMZ, FireWall...)
Se si vogliono eseguire richieste nascondendo la propria origine
...

Demo `8-ssrf-14.1.0`

Contesto

SSRF A

https://www.assetnote.io/resources/research/digging-for-ssrf-in-nextjs-apps

Obiettivo

SSRF B, obiettivo

Condizioni per sfruttare la CVE-2024-34351

Un'applicazione basata su Next.JS con versione inferiore alla 14.1.1
L'uso della funzione redirect, con un percorso assoluto. Nella demo, in addTodo.js: redirect(/blog/${inputValue});

Funzionamento della funzione redirect

Fonte: https://www.assetnote.io/resources/research/digging-for-ssrf-in-nextjs-apps

La funzione Next.JS redirect non restituisce una risposta HTTP 302 al browser.

Next.JS esegue la richiesta lato server, poi restituisce il risultato al browser:

Per eseguire la richiesta, Next.JS deve costruire l'URL da chiamare. Nella demo, in addTodo.js: La funzione redirect('/blog/123'); costruisce l'URL http://207.154.209.99/blog/123. Per costruire questo URL, Next.JS recupera in particolare l'host 207.154.209.99 dall'header HTTP della richiesta iniziale.
Next.JS inizia interrogando l'URL con una richiesta HTTP HEAD.
Se la risposta restituisce un header Content-Type: text/x-component, allora Next.JS interroga l'URL con una richiesta HTTP GET.

SSRF C, introduzione

Sfruttamento

Per ottenere un SSRF sul server di destinazione, è quindi necessario eseguire un altro server:

che ascolti su tutte le route (query path)
che restituisca un HTTP 200 con un header Content-Type: text/x-component, per ogni richiesta HEAD
che restituisca un HTTP 302 verso il server di destinazione, per ogni richiesta GET

SSRF D, exploit

gif demo exploit

Correzione della vulnerabilità in `8-ssrf-14.1.0`

Soluzione 1 (non permanente): configurazione di nginx per forzare l'host

In /etc/nginx/sites-available/nextjs

Prima:

server {
  listen 80 default_server;
  location / {
    proxy_pass http://localhost:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_cache_bypass $http_upgrade;
  }
}

Dopo:

server {
  listen 80;
  server_name 207.154.209.99;
  location / {
    proxy_pass http://localhost:3000;
    proxy_set_header Host 207.154.209.99;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_cache_bypass $http_upgrade;
  }
}

Rischio di effetti collaterali...

https://nginxtutorials.com/nginx-proxy_set_header-directive/

Soluzione 2: aggiornare Next.js

https://github.com/vercel/next.js/security/advisories/GHSA-fr5h-rqp8-mj6g

Note

"Extra attributes from the server"

https://stackoverflow.com/questions/75337953/what-causes-nextjs-warning-extra-attributes-from-the-server-data-new-gr-c-s-c

"getStaticProps" is not supported in app/. Read more: https://nextjs.org/docs/app/building-your-application/data-fetching

https://nextjs.org/docs/app/building-your-application/upgrading/app-router-migration#static-site-generation-getstaticprops

create-next-app

https://nextjs.org/docs/app/building-your-application/upgrading/app-router-migration#step-4-migrating-pages

Le pagine nella directory app sono Server Components per impostazione predefinita. Questo è diverso dalla directory pages, dove le pagine sono Client Components.

L'aggiornamento a Next.js 13 non richiede l'uso del nuovo App Router. Puoi continuare a usare le pagine con le nuove funzionalità che funzionano in entrambe le directory

Performance

Se si vogliono confrontare le performance di caricamento delle diverse soluzioni, si possono aggiungere le metriche Core Web Vitals in console.log.

https://web.dev/articles/fcp?hl=fr

altre fonti / riferimenti

https://rsc-parser.vercel.app/

https://stackoverflow.com/questions/76325862/what-is-the-difference-between-react-server-components-rsc-and-server-side-ren

https://github.com/reactjs/server-components-demo?tab=readme-ov-file#should-i-use-this-demo-for-benchmarks

https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md#does-this-replace-ssr

https://www.youtube.com/watch?v=jEJEFAc8tSI

ISR usando l'App router?

https://nextjs.org/docs/pages/building-your-application/data-fetching/incremental-static-regeneration

Nel Next.js App Router, tutti i dati recuperati sono ora statici per impostazione predefinita, renderizzati in fase di build. Tuttavia, questo può essere facilmente modificato: Next.js estende l'oggetto delle opzioni di fetch per fornire flessibilità nelle regole di caching e revalidation. Puoi usare l'opzione {next: {revalidate: number}} per aggiornare i dati statici a intervalli prestabiliti o quando si verificano modifiche al backend (Incremental Static Regeneration), mentre l'opzione {cache: 'no-store'} può essere passata nella richiesta fetch per i dati dinamici (server-side rendering).

https://www.telerik.com/blogs/current-state-react-server-components-guide-perplexed

https://react.dev/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components

https://github.com/reactjs/server-components-demo

https://dev.to/vteacher/let-s-make-a-web-application-with-react-server-components-5dmg

https://react.dev/blog/2024/04/25/react-19

https://react.dev/reference/rsc/server-components

https://www.youtube.com/watch?v=ePAPd9qzGyM

https://www.joshwcomeau.com/react/server-components/

https://nextjs.org/docs/app/building-your-application/rendering/server-components#server-rendering-strategies

https://nextjs.org/docs/pages/building-your-application/rendering/static-site-generation

https://nextjs.org/docs/pages/building-your-application/data-fetching/get-static-props

https://react.dev/reference/rsc/server-components#server-components-without-a-server