Security flaws in a simple smart contract

Question

I developed a simple smart contract to store two privacy preferences for a user. I am testing and evaluating this contract on a private blockchain via Ganache.

I am currently validating the security of it but I have some doubts. In my research I identified three flaws that could affect this contract: Reentrancy, Front-Running and DoS with Block Stuffing (Details of the attacks can be seen here).

My main question is:

• How to evaluate these issues in the developed contract?

1) To evaluate Reentrancy I thought of invoking one of the contract's functions several times at the same time. Would this idea be valid? How can I do to invoke this function several times at the same time?

2) For Front-Running I thought of monitoring the mempool and checking if I can observe the transaction before it is executed. The question is: how to do this via ganache?

3) For DoS, I thought again about calling a function repeatedly until the gas limit of the block is reached. Would this idea be valid?

Below is the contract code:

pragma solidity ^0.5.0;

contractPrivacyPreferences {

bool preference = false;
bool monitoringType = false;


mapping (address => bool) addresses;

contructor () public {
    adresses [address(0x00281055afc982d96fab65b3a49cac8b878184cb16)] = true;
}

function changePreferences() public {
     if (addresses [msg.sender])
           preference = true;
}

function changeMonitoringType () public {
   if (addresses [msg.sender]) {
      monitoringType = true;
}

function preferenceStatus() public view returns (bool) {
    return preference;
}

function monitoringStatus() public view returns (bool) {
    return monitoringType;
}
}

Answer 1

This are some rules I follow when verifying smart contracts

1. Reentracy: Can a function be invoked by a third party while another function hasn't finished? This requires a function transferring control to another contract.

   Your contract doesn't make calls neither transfer ethers, so it shouldn't be exploitable by reentrancy issues.

2. Front running: Does transaction ordering affect outcome? Front running is when someone looking at pending transactions can alter the expected behavior by inserting its own transactions in front of others.

   There's no issue if someone else change the order the final results will be the same.

3. Denial of service: Does contract have a behavior other than O(1) that can be cheaply abused?

   There behavior in general is O(1) so there's no possible denial of service attacks.

Note: Your contract is very simple, easy to analyze, and it is very clear to rule out these attacks. In more complex contracts the outcome sometimes might not be as clear as in this case.