Security and UDPClient

  • Thread starter Thread starter M D
  • Start date Start date
M

M D

Apparently to use the UDPClient users will have to open an IP port on
there firewalls. What is the risk? If I structure all my messages and
test for compliance on each packet received will I be doing all that is
possible to stop unauthorized use of the port? Is there anything I
should do to destroy unrecognized packets?

And what does a user do when my app is not listening to the port? Is
the port only accessable when an app is using it?

thx
md
 
Apparently to use the UDPClient users will have to open an IP port on
there firewalls. What is the risk? If I structure all my messages and
test for compliance on each packet received will I be doing all that is
possible to stop unauthorized use of the port? Is there anything I
should do to destroy unrecognized packets?
Click to expand...

With any udp or tcp listener, the port needs to be open on firewall to allow
access to it. If you validate the packet (i.e. byte[] ) and it is bad, then
just drop it (let it go out of scope or set it to null and move on. One the
UDPclient gives you the byte[] then you need to deal with it as it does not
keep a ref to it any longer. So you can just ignore it and wait on next
byte[] if you want.
And what does a user do when my app is not listening to the port? Is
the port only accessable when an app is using it?
Click to expand...

yes. The port is only accessable when an app is listening on it. If app is
not running, then any app on the system could start listening on that port
or any free port.
 
I recently saw an article on InfoWorld or somewhere about invading code
getting into unaccounted-for memory allocations and something about it's
being called when Windows performs memory management. I made me think
that rather than just setting the reference to null or abandoning it I
should null out each byte in byte[].

thx
md
 
M D said:
I recently saw an article on InfoWorld or somewhere about invading code
getting into unaccounted-for memory allocations and something about it's
being called when Windows performs memory management. I made me think
that rather than just setting the reference to null or abandoning it I
should null out each byte in byte[].
Click to expand...

No need, data you receive is not hostile (a series of bytes are not a
treat).
What is hostile is what you do with the data (a specific sequence of data
that makes your software react in a way you did not intended, but it is your
software that does the wrong thing, not the data).

In the other respect we have a buffer overflow, which can cause stack
corruption, in which case you return to an undefined address and cause
corruption. That should not be possible in VB.NET or C#, this means at least
in a much lesser extend than in C/C++ directly with Win32 API.

- Joris
 
Back
Top