Skip to main content

Return to Question

fixed typo
Source Link
Adriano
Adriano
  • 4k
  • 5
  • 36
  • 58

Intro

This topic has been the bane of many questions and answers on StackOverflow -and in many other tech-forums; however, most of them are specific to exact conditions and even worse: "over-all" security in script-injection prevention via dev-tools-console, or dev-tools-elements or even address-bar is said to be "impossible" to protect. This question is to address these issues and serve as current and historical reference as technology improves -or new/better methods are discovered to address browser security issues -specifically related to script-injection attacks.

Concerns

There are many ways to either extract -or manipulate information "on the fly"; specifically, it's very easy to intercept information gathered from input -to be transmitted to the server - regardless of SSL/TLS.

intercept example

Have a look here Regardless of how "crude" it is, one can easily use the principle to fabricate a template to just copy+paste into an eval() in the browser console to do all kinds of nasty things such as:

  • console.log() intercepted information in transit via XHR
  • manipulate POST-data, changing user-references such as UUIDs
  • feed the target-server alternative GET (& post) request information to either relay (or gain) info by inspecting the JS-code, cookies and headers

This kind of attack "seems" trivial to the untrained eye, but when highly dynamic interfaces are in concern, then this quickly becomes a nighmarenightmare -waiting to be exploited.

We all know "you can't trust the front-end" and the server should be responsible for security; however - what about the privacy/security of our beloved visitors? Many people create "some quick app" in JavaScript and either do not know (or care) about the back-end security.

Securing the front-end as well as the back-end would prove formidable against an average attacker, and also lighten the server-load (in many cases).

Efforts

Both Google and Facebook have implemented some ways of mitigating these issues, and they work; so it is NOT "impossible", however, they are very specific to their respective platforms and to implement requires the use of entire frameworks plus a lot of work -only to cover the basics.

Regardless of how "ugly" some of these protection mechanisms may appear; the goal is to help (mitigate/prevent) security issues to some degree, making it difficult for an attacker. As everybody knows by now: "you cannot keep a hacker out, you can only discourage their efforts".

Tools & Requirements

The goal is to have a simple set of tools (functions):

  • these MUST be in plain (vanilla) javascript
  • together they should NOT exceed a few lines of code (at most 200)
  • they have to be immutable, preventing "re-capture" by an attacker
  • these MUST NOT clash with any (popular) JS frameworks, such as React, Angular, etc
  • does NOT have to be "pretty", but readable at least, "one-liners" welcome
  • cross-browser compatible, at least to a good percentile

Intro

This topic has been the bane of many questions and answers on StackOverflow -and in many other tech-forums; however, most of them are specific to exact conditions and even worse: "over-all" security in script-injection prevention via dev-tools-console, or dev-tools-elements or even address-bar is said to be "impossible" to protect. This question is to address these issues and serve as current and historical reference as technology improves -or new/better methods are discovered to address browser security issues -specifically related to script-injection attacks.

Concerns

There are many ways to either extract -or manipulate information "on the fly"; specifically, it's very easy to intercept information gathered from input -to be transmitted to the server - regardless of SSL/TLS.

intercept example

Have a look here Regardless of how "crude" it is, one can easily use the principle to fabricate a template to just copy+paste into an eval() in the browser console to do all kinds of nasty things such as:

  • console.log() intercepted information in transit via XHR
  • manipulate POST-data, changing user-references such as UUIDs
  • feed the target-server alternative GET (& post) request information to either relay (or gain) info by inspecting the JS-code, cookies and headers

This kind of attack "seems" trivial to the untrained eye, but when highly dynamic interfaces are in concern, then this quickly becomes a nighmare -waiting to be exploited.

We all know "you can't trust the front-end" and the server should be responsible for security; however - what about the privacy/security of our beloved visitors? Many people create "some quick app" in JavaScript and either do not know (or care) about the back-end security.

Securing the front-end as well as the back-end would prove formidable against an average attacker, and also lighten the server-load (in many cases).

Efforts

Both Google and Facebook have implemented some ways of mitigating these issues, and they work; so it is NOT "impossible", however, they are very specific to their respective platforms and to implement requires the use of entire frameworks plus a lot of work -only to cover the basics.

Regardless of how "ugly" some of these protection mechanisms may appear; the goal is to help (mitigate/prevent) security issues to some degree, making it difficult for an attacker. As everybody knows by now: "you cannot keep a hacker out, you can only discourage their efforts".

Tools & Requirements

The goal is to have a simple set of tools (functions):

  • these MUST be in plain (vanilla) javascript
  • together they should NOT exceed a few lines of code (at most 200)
  • they have to be immutable, preventing "re-capture" by an attacker
  • these MUST NOT clash with any (popular) JS frameworks, such as React, Angular, etc
  • does NOT have to be "pretty", but readable at least, "one-liners" welcome
  • cross-browser compatible, at least to a good percentile

Intro

This topic has been the bane of many questions and answers on StackOverflow -and in many other tech-forums; however, most of them are specific to exact conditions and even worse: "over-all" security in script-injection prevention via dev-tools-console, or dev-tools-elements or even address-bar is said to be "impossible" to protect. This question is to address these issues and serve as current and historical reference as technology improves -or new/better methods are discovered to address browser security issues -specifically related to script-injection attacks.

Concerns

There are many ways to either extract -or manipulate information "on the fly"; specifically, it's very easy to intercept information gathered from input -to be transmitted to the server - regardless of SSL/TLS.

intercept example

Have a look here Regardless of how "crude" it is, one can easily use the principle to fabricate a template to just copy+paste into an eval() in the browser console to do all kinds of nasty things such as:

  • console.log() intercepted information in transit via XHR
  • manipulate POST-data, changing user-references such as UUIDs
  • feed the target-server alternative GET (& post) request information to either relay (or gain) info by inspecting the JS-code, cookies and headers

This kind of attack "seems" trivial to the untrained eye, but when highly dynamic interfaces are in concern, then this quickly becomes a nightmare -waiting to be exploited.

We all know "you can't trust the front-end" and the server should be responsible for security; however - what about the privacy/security of our beloved visitors? Many people create "some quick app" in JavaScript and either do not know (or care) about the back-end security.

Securing the front-end as well as the back-end would prove formidable against an average attacker, and also lighten the server-load (in many cases).

Efforts

Both Google and Facebook have implemented some ways of mitigating these issues, and they work; so it is NOT "impossible", however, they are very specific to their respective platforms and to implement requires the use of entire frameworks plus a lot of work -only to cover the basics.

Regardless of how "ugly" some of these protection mechanisms may appear; the goal is to help (mitigate/prevent) security issues to some degree, making it difficult for an attacker. As everybody knows by now: "you cannot keep a hacker out, you can only discourage their efforts".

Tools & Requirements

The goal is to have a simple set of tools (functions):

  • these MUST be in plain (vanilla) javascript
  • together they should NOT exceed a few lines of code (at most 200)
  • they have to be immutable, preventing "re-capture" by an attacker
  • these MUST NOT clash with any (popular) JS frameworks, such as React, Angular, etc
  • does NOT have to be "pretty", but readable at least, "one-liners" welcome
  • cross-browser compatible, at least to a good percentile
removed tag from title
Link
Derek Pollard
Derek Pollard
  • 7.2k
  • 6
  • 45
  • 62

Javascript - how How to prevent script injection attacktsattacks

added 2 characters in body
Source Link
argon
argon
  • 449
  • 5
  • 12

Intro

This topic has been the bane of many questions and answers on StackOverflow -and in many other tech-forums; however, most of them are specific to exact conditions and even worse: "over-all" security in script-injection prevention via dev-tools-console, or dev-tools-elements or even address-bar is said to be "impossible" to protect. This question is to address these issues and serve as current and historical reference as technology improves -or new/better methods are discovered to address browser security issues -specifically related to script-injection attacks.

Concerns

There are many ways to either extract -or manipulate information "on the fly"; specifically, it's very easy to intercept information gathered from input -to be transmitted to the server - regardless of SSL/TLS.

intercept example

Have a look here Regardless of how "crude" it is, one can easily use the principle to fabricate a template to just copy+paste into an eval() in the browser console to do all kinds of nasty things such as:

  • console.log() intercepted information in transit via XHR
  • manipulate POST-data, changing user-references such as UUIDs
  • feed the target-server alternative GET (& post) request information to either relay (or gain) info by inspecting the JS-code, cookies and headers

This kind of attack "seems" trivial to the untrained eye, but when highly dynamic interfaces are in concern, then this quickly becomes a nighmare -waiting to be exploited.

We all know "you can't trust the front-end" and the server should be responsible for security; however - what about the privacy/security of our beloved visitors? Many people create "some quick app" in JavaScript and either do not know (or care) about the back-end security.

Securing the front-end as well as the back-end would prove formidable against an average attacker, and also lighten the server-load (in many cases).

Efforts

Both Google and Facebook have implemented some ways of mitigating these issues, and they work; so it is NOT "impossible", however, they are very specific to their respective platforms and to implement requires the use of entire frameworks plus a lot of work -only to cover the basics.

Regardless of how "ugly" some of these protection mechanisms may appear; the goal is to help (mitigate/prevent) security issues to some degree, making it difficult for an attacker. As everybody knows by now: "you cannot keep a hacker out, you can only discourage their efforts".

Tools & Requirements

The goal is to have a simple set of tools (functions):

  • these MUST be in plain (vanilla) javascript
  • together they should NOT exceed a few lines of code (at most 200)
  • they have to be immutable, preventing "re-capture" by an attacker
  • these MUST NOT clash with any (popular) JS frameworks, such as React, Angular, etc
  • does NOT have to be "pretty", but readable at least, "one-liners" welcome
  • cross-browser compatible, at least to a good percentile

Intro

This topic has been the bane of many questions and answers on StackOverflow -and in many other tech-forums; however, most of them are specific to exact conditions and even worse: "over-all" security in script-injection prevention via dev-tools-console, or dev-tools-elements or even address-bar is said to be "impossible" to protect. This question is to address these issues and serve as current and historical reference as technology improves -or new/better methods are discovered to address browser security issues -specifically related to script-injection attacks.

Concerns

There are many ways to either extract -or manipulate information "on the fly"; specifically, it's very easy to intercept information gathered from input -to be transmitted to the server - regardless of SSL/TLS.

intercept example

Have a look here Regardless of how "crude" it is, one can easily use the principle to fabricate a template to just copy+paste into an eval() in the browser console to do all kinds of nasty things such as:

  • console.log() intercepted information in transit via XHR
  • manipulate POST-data, changing user-references such as UUIDs
  • feed the target-server alternative GET (& post) request information to either relay (or gain) info by inspecting the JS-code, cookies and headers

This kind of attack "seems" trivial to the untrained eye, but when highly dynamic interfaces are in concern, then this quickly becomes a nighmare -waiting to be exploited.

We all know "you can't trust the front-end" and the server should be responsible for security; however - what about the privacy/security of our beloved visitors? Many people create "some quick app" in JavaScript and either do not know (or care) about the back-end security.

Securing the front-end as well as the back-end would prove formidable against an average attacker, and also lighten the server-load (in many cases).

Efforts

Both Google and Facebook have implemented some ways of mitigating these issues, and they work; so it is NOT "impossible", however, they are very specific to their respective platforms and to implement requires the use of entire frameworks plus a lot of work -only to cover the basics.

Regardless of how "ugly" some of these protection mechanisms may appear; the goal is to help (mitigate/prevent) security issues to some degree, making it difficult for an attacker. As everybody knows by now: "you cannot keep a hacker out, you can only discourage their efforts".

Tools & Requirements

The goal is to have a simple set of tools (functions):

  • these MUST be in plain (vanilla) javascript
  • together they should NOT exceed a few lines of code (at most 200)
  • they have to be immutable, preventing "re-capture" by an attacker
  • these MUST NOT clash with any (popular) JS frameworks, such as React, Angular, etc
  • does NOT have to be "pretty", but readable at least, "one-liners" welcome
  • cross-browser compatible, at least to a good percentile

Intro

This topic has been the bane of many questions and answers on StackOverflow -and in many other tech-forums; however, most of them are specific to exact conditions and even worse: "over-all" security in script-injection prevention via dev-tools-console, or dev-tools-elements or even address-bar is said to be "impossible" to protect. This question is to address these issues and serve as current and historical reference as technology improves -or new/better methods are discovered to address browser security issues -specifically related to script-injection attacks.

Concerns

There are many ways to either extract -or manipulate information "on the fly"; specifically, it's very easy to intercept information gathered from input -to be transmitted to the server - regardless of SSL/TLS.

intercept example

Have a look here Regardless of how "crude" it is, one can easily use the principle to fabricate a template to just copy+paste into an eval() in the browser console to do all kinds of nasty things such as:

  • console.log() intercepted information in transit via XHR
  • manipulate POST-data, changing user-references such as UUIDs
  • feed the target-server alternative GET (& post) request information to either relay (or gain) info by inspecting the JS-code, cookies and headers

This kind of attack "seems" trivial to the untrained eye, but when highly dynamic interfaces are in concern, then this quickly becomes a nighmare -waiting to be exploited.

We all know "you can't trust the front-end" and the server should be responsible for security; however - what about the privacy/security of our beloved visitors? Many people create "some quick app" in JavaScript and either do not know (or care) about the back-end security.

Securing the front-end as well as the back-end would prove formidable against an average attacker, and also lighten the server-load (in many cases).

Efforts

Both Google and Facebook have implemented some ways of mitigating these issues, and they work; so it is NOT "impossible", however, they are very specific to their respective platforms and to implement requires the use of entire frameworks plus a lot of work -only to cover the basics.

Regardless of how "ugly" some of these protection mechanisms may appear; the goal is to help (mitigate/prevent) security issues to some degree, making it difficult for an attacker. As everybody knows by now: "you cannot keep a hacker out, you can only discourage their efforts".

Tools & Requirements

The goal is to have a simple set of tools (functions):

  • these MUST be in plain (vanilla) javascript
  • together they should NOT exceed a few lines of code (at most 200)
  • they have to be immutable, preventing "re-capture" by an attacker
  • these MUST NOT clash with any (popular) JS frameworks, such as React, Angular, etc
  • does NOT have to be "pretty", but readable at least, "one-liners" welcome
  • cross-browser compatible, at least to a good percentile
fixed typo
Link
argon
argon
  • 449
  • 5
  • 12
Source Link
argon
argon
  • 449
  • 5
  • 12