user73342: In many cryptocurrencies a TX is composed of an array of TX inputs and TX outputs. 
When a TX is submitted to the network, it already has the signature (in the unlocking script). 
So my question is, what does prevent a miner or anyone on the network to use the already present unlocking and change the locking scripts of the transactions and then propagate the transaction. 
Because in my understanding I may provide a signature to unlock a txo and someone uses my signature to change the locking scripts of those TXs.

user38482: 
Because in my understanding I may provide a signature to unlock a txo
  and someone uses my signature to change the locking scripts of those
  TXs.

Taking a "P2PKH tx", the unlockscript requires some operations to be executed while spending a tx:
<sig><pubkey><OP_DUP><OP_HASH160>pk hash<OP_EQUALVERIFY><OP_CHECKSIG>

I have three scenarios here, when changing parts of the script fields:
1.) change <sig> and <pubkey>
a miner changes the  part with a new signature and pubkey. Assuming the block raelly gets "through", the spender of the funds has a problem, cause his  would not match to the hash of the  anymore.
2.) change only the <sig>
a miner changes only the  part with a new signature. Now the spender's  would match the hash of the . However the last command <OP_CHECKSIG> would check the remaining parts on the stack (<new sig><pubkey>), and this would (obviously) fail.
3.) change the pubkey script
when anything in the pubkey script is changed, then the signature process will fail. During creat
ion of the signed transaction, the sigscipt area is filled with the pubkey script, and then signe
d. Later on, before transmitting the tx, the sciptsig area is replaced with <signature><pubkey>.
So when the block would be propagated to other nodes, they would verify this block and it's tx in
side, and discover a signature mismatch. 
Pieter explained details here of the scriptsig here:
What are the parts of a Bitcoin Transaction "Input" script?
and two references that further help to understand:
1) http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html
2) Andreas' book "Mastering Bitcoin", 2nd Edition, page 135ff

user208: Signatures cover inputs and outputs.
If someone changes one of the outputs in a transaction, a new signature is required. Effectively your signature signs "permit using my UTXO X to send A BTC to B, C BTC to D, ...".

73342: <p>In many cryptocurrencies a TX is composed of an array of TX inputs and TX outputs. </p>

<p>When a TX is submitted to the network, it already has the signature (in the unlocking script). </p>

<p>So my question is, what does prevent a miner or anyone on the network to use the already present unlocking and change the locking scripts of the transactions and then propagate the transaction. </p>

<p>Because in my understanding I may provide a signature to unlock a txo and someone uses my signature to change the locking scripts of those TXs.</p>
 38482: <blockquote>
  <p>Because in my understanding I may provide a signature to unlock a txo
  and someone uses my signature to change the locking scripts of those
  TXs.</p>
</blockquote>

<p>Taking a "P2PKH tx", the unlockscript requires some operations to be executed while spending a tx:</p>

<pre><code>&lt;sig&gt;&lt;pubkey&gt;&lt;OP_DUP&gt;&lt;OP_HASH160&gt;pk hash&lt;OP_EQUALVERIFY&gt;&lt;OP_CHECKSIG&gt;
</code></pre>

<p>I have three scenarios here, when changing parts of the script fields:</p>

<p><strong>1.) change <code>&lt;sig&gt;</code> and <code>&lt;pubkey&gt;</code></strong></p>

<p>a miner changes the  part with a new signature and pubkey. Assuming the block raelly gets "through", the spender of the funds has a problem, cause his  would not match to the hash of the  anymore.</p>

<p><strong>2.) change only the <code>&lt;sig&gt;</code></strong></p>

<p>a miner changes only the  part with a new signature. Now the spender's  would match the hash of the . However the last command <code>&lt;OP_CHECKSIG&gt;</code> would check the remaining parts on the stack (<code>&lt;new sig&gt;&lt;pubkey&gt;</code>), and this would (obviously) fail.</p>

<p><strong>3.) change the pubkey script</strong></p>

<p>when anything in the pubkey script is changed, then the signature process will fail. During creat
ion of the signed transaction, the sigscipt area is filled with the pubkey script, and then signe
d. Later on, before transmitting the tx, the sciptsig area is replaced with <code>&lt;signature&gt;&lt;pubkey&gt;</code>.
So when the block would be propagated to other nodes, they would verify this block and it's tx in
side, and discover a signature mismatch. </p>

<p>Pieter explained details here of the scriptsig here:
<a href="https://bitcoin.stackexchange.com/questions/57644/what-are-the-parts-of-a-bitcoin-transaction-input-script">What are the parts of a Bitcoin Transaction &quot;Input&quot; script?</a></p>

<p>and two references that further help to understand:</p>

<p>1) <a href="http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html" rel="nofollow noreferrer">http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html</a></p>

<p>2) Andreas' book "Mastering Bitcoin", 2nd Edition, page 135ff</p>
 208: <p>Signatures cover inputs and outputs.</p>

<p>If someone changes one of the outputs in a transaction, a new signature is required. Effectively your signature signs "permit using my UTXO X to send A BTC to B, C BTC to D, ...".</p>
