New answers tagged security
0
One simple trick could be host geth on separate server and only allow rpc over localhost. Then write a simple api on geth server which will receive requests from your other server, interact with geth and send you back the response. You can secure your api by adding some private key to the routes so that nobody can visit those api urls unless they know the ...
0
If you're worried about someone bruteforcing (or rainbow tables as your question suggests) the input you can use something called Salts ( https://en.wikipedia.org/wiki/Salt_(cryptography) ). That way there's no way to bruteforce the input if the salt is kept secret as well. People can't change their secret upon will without spending a lot of effort in ...
0
A contract can't access the gas limit in a transaction.
Maybe msg.gas could be used, but gas specific code should be avoided because gas costs can and will change.
For example, the gas cost for SLOAD was raised from 50 to 200 in 2016, and again in 2019 in EIP 1884, with some impacts described in:
https://chainsecurity.com/istanbul-hardfork-eips-increasing-...
1
The gasLimit is a property of the blocks but I interpreted your question as "transaction gas supplied."
If I'm not wrong, you can't go all the way back to the gas supplied for a transaction but you can watch the gas as a transaction runs with msg.gas which will give you the gas remaining, on that step, from the amount that was sent to your function.
What ...
1
There is reentrancy example code you can try out here: https://github.com/KevinSmall/SolidityContractVulnerabilities#reentrancy
2
If daiToken were a malicious contract once you have invoked transferFrom then it can call your deposit function before it has finished executing the first time so potentially amount is credited multiple times.
But to be honest ERC20 doesn't guarantee even if you call transferFrom successfully that the transfer of tokens will be OK. You have to trust that it ...
0
First of all are you sure to add amount to the msg.sender account BEFORE than he pays by the daitoken his augmented balance? If I understood well, is a reentrancy attack hook quite perfect... you have the effect BEFORE the payment.
A part from this, very probably remix is not able to understand the reference to the daitoken contract, in the sense that it ...
0
Just to amplify Lauri's answer, the question could be rephrased,
What if I don't trust my own equipment?
That is possibly a concern, but it isn't limited to the Ethereum node. It goes all the way to the metal. Exactly what you want to do about that will depend on the value you attach to the asset you want to protect. No one is stopping you from, for ...
2
This is not exactly about trusting a random node. This is about trusting the node you use to communicate with the blockchain - you most likely issue both types of transactions to the same node. If you don't trust that node then you can't trust anything really - you can't even know whether the node is even really connected to the blockchain or whether it just ...
2
No.
Your Mutex (locked) will prevent reentrance but reentrance is not the only vulnerability.
A DoS is possible and it might not be intentional.
This line, after payment 2:
require(success, "Transfer failed.");
Have you considered that payment 1 will not happen if the transaction aborts at this stage? That means player1 doesn't get paid unless ...
6
It sounds like you are being front run. This means that a bot is watching you send a transaction, reading the input (specifically, _answer), and submitting a transaction with the correct answer but a higher gasPrice. A miner will accept their transaction before yours, causing theirs to succeed and yours to fail.
You can see that this is, in fact, what is ...
Top 50 recent answers are included
