CDATA escaping for inline <script> and <style> tags
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
Direzione di ricerca
Start by tracing the AST and renderer paths used for inline style elements and the proposed script helper, focusing on the Raw behavior described in the issue. Compare the safety check in blaze-markup's Text renderer, then verify that special characters render correctly while closing-tag sequences cannot produce invalid HTML or XSS.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
#3 accidentally introduced a regression wrt. to CSS rendering. <script> and <style> tags are special in HTML, as they are encoded as CDATA. That essentially means – no escaping, but closing tag can't appear in the payload content and HTML does not provide a way to escape this.
At the moment:
<style>elements generated by web-view use regular text escaping, thus, if they contain any of escaped characters (<>&"' etc.) rendered CSS will be incorrect,<script>element that we don't have a helper now will: either cause invalid JS to be rendered (iftextis used) or invalid HTML (with the risk of opening XSS vulnerability) ifrawis used – the latter was also the case for CSS before #3 was merged.
For example, addClass $ cls "test" & prop "background" ("url('https://picsum.photos/200/300?random=1&foo=2=bar')" :: Text)) will generate incorrect result:
<style type='text/css'>
.empty { background:url('https://picsum.photos/200/300?random=1&foo=2=bar') }
</style>
Potential solution could be to introduce External to AST, which would be always the same as Raw but would refuse to include any </ sequence which would prevent XSS/invalid HTML. This is what blaze-markup does for these tags.
Trivia: Historically, people would split string literals in JS payloads to "escape" them, e.g.
<script>document.write('<scr'+'ipt type="text/javascript" src="http://example.com/some.js"></sc'+'ript>');</script>
- Lingua principale
- Haskell
- Stelle
- 56
- Fork
- 7
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di seanhess/atomic-css
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 55/100
seanhess/atomic-css#30 · 3 commenti ·
Tutte le issue di seanhess/atomic-css
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
IntersectMBO/cardano-ledger#6276 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
OpenZeppelin/canton-contracts#92 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
hasura/graphql-engine#10954 ·
I maintainer di solito rispondono entro 1 giorno