TodePond / DreamBerd

perfect programming language
https://dreamberd.computer
Other
11.41k stars 357 forks source link

Increase const-ness of variables in scope to prevent unauthorized modification #444

Open stefan-isc opened 1 year ago

stefan-isc commented 1 year ago

Hello

We have encountered a minor inconvenience while using DreamBerd in a production environment. Hackers can sometimes modify data and variables when parsing/processing user input.

To mitigate this issue, we propose introducing a feature that allows us to temporarily increase the const-ness of specific critical variables (e.g., other users' balance) before processing user input. After the processing is complete, we should be able to decrease the const-ness accordingly. This enhancement would prevent unauthorized modification of variables and significantly strengthen the security of our system.

Example Code:

// here we store the balance of all users in the system
var var balances = [240, 5000, 200, 100, ...]!

make_const_const (balances) { // this makes the balances variable constant (even a hacker could not change it)
   // parse and process user input
   process_user_input()!
   // ...
} // now it is variable again, but user input was already processed

We are looking forward to your feedback and potential implementation of this feature.

PokeJofeJr4th commented 1 year ago

in my DreamBerd rs implementation you can do

var var balance = 2!
// most of our program can easily access this value
{
  // inner definition shadows original balance, and the value is copied
  const const balance = balance!
  process_user_input()!
}
// we can access the outer value once the block ends

Of course, if you really wanted to prevent hackers from stealing your data, you'd use a language like Haskell, which can be mathematically proven to be secure (incapable of performing basic tasks necessary for your use case)

thegatesdev commented 10 months ago

// inner definition shadows original balance, and the value is copied const const balance = balance!

This would still mean the original mutable value is present in the scope of the user interaction, meaning it could still be changed using constructs like before. Preferably, make_const_const would make this impossible. However, a safer way of allowing mutability by only specific parts of our code would be to add a whitelist for functions being able to mutate a const const variable:

const const(allows someOtherFunction) balance = 68!
process_user_input()! // We are safe, balance can only be mutated by someOtherFunction