1

I'm developing a React web app where the user can input a .csv of their transaction data, and the app will output useful analysis that will inform their future purchase decisions.

I'm planning to use an input component for the user to input their csv file, then I'll save it in the app's state and use it for analysis

const [csv, setCsv] = useState<FileList | null>();

const handleOnSubmit = () => {
  if (csv) {
    //Convert csv to json
    //Sort and output useful data or something here
  }
};

<input
  type="file"
  name="csv_upload"
  accept=".csv"
  onChange={(e) => {
    setCsv(e.target.files);
  }}
/>

<button type="button" onClick={handleOnSubmit}>
  Analyze
</button>

As you can see, this is something I definitely don't wanna mess up because it's dealing with sensitive data. My knowledge of attacks in the web dev world only includes SQL injections and DoS, but that's about it. I'm not planning to use a back-end server for this, so I'm not sure if an attacker can still obtain these sensitive data from the client side unless they get a hold of the user's pc.

I'm also thinking about encrypting the data as well, but I'm not sure how well that's gonna work because the encrypt and decrypt function are gonna be in the same place (there's only the client side, so only 1 place where the code will live in) so it's like locking the door then leaving the key right next to it...

  • Are there any possible attacks an attacker can make on this web app to obtain the user's transaction data? And if so, can you guys suggest some things I can do to prevent that?
Sir Muffington
  • 1,536
  • 2
  • 11
  • 23
Khang
  • 11
  • 1
  • 2
    It's clear from your question that your application processes the CSV file client-side (or 'in browser), using javascript. But wrt ' web site that doesn't use a back-end server' - the javascript must be served from some server. This is an attack vector. If the attacker compromises the server, or is able to pull-off a MITM attack between the client and the server, then he can change the client-side code, such that the CSV file is uploaded to his server. SSL/TLS certificates can be used to thwart an MTIM. But, still the user must trust you and your server, and that you will not go rogue. – mti2935 Feb 18 '22 at 16:42
  • If I host this website on github pages or heroku, would it help since they'd need to go through github or heroku's security system to compromise the server? Would they also help with SSL/TLS certificate to thwart an MTIM too? For the last point, I thought if I made the repository public, it could help keeping the user's trust, but at the same time I'm also letting attackers know exactly how to work around the securities . . . – Khang Feb 19 '22 at 00:42
  • It's an interesting idea, but most users are not technical enough to do code review. Even if they can, what assures that the code that is served is the same as the code in the public repo? Regardless of where you host the pages and client-side code, the user must trust that your account has not been compromised, and that you have not gone rogue. – mti2935 Feb 19 '22 at 01:47
  • 1
    This question boils down to the `chicken-and-egg problem` with in-browser scripting. You are using in-browser scripting, because the user doesn't trust your server with their secrets. But, if the user does not trust your server with their secrets, then how can they trust your server (or GitHub's server, or heroku's server) to serve secure in-browser scripting? See https://security.stackexchange.com/questions/238441/solution-to-the-browser-crypto-chicken-and-egg-problem for some interesting reading on this problem. – mti2935 Feb 19 '22 at 01:48
  • Thank you for your link, this was a very interesting read! Maybe this is better off being a portfolio piece or a proof of concept, and I'll just make a dummy .csv for the user to play around with. Thanks again for your comments! – Khang Feb 19 '22 at 02:47

1 Answers1

1

If you read a search of the CVEs for React, you can get a sense for the scope of possible vulnerabilities.

Mostly it is a lot of cross-site scripting vulnerabilities.

Tyler Durden
  • 1,116
  • 1
  • 9
  • 18