Advertisement

how to know most hack possiblities and find best way to handle them

Started by January 08, 2015 09:28 PM
39 comments, last by moeen k 9 years, 9 months ago

But it's the C-code that has the issue, not the PHP-code. You cannot _create_ these kinds of issues with PHP, but can certainly be affected by them. (With that said, PHP in particular is, in my own humble opinion, not really something you should ever use if you have an option. After following the development mailing list for years, I can honestly say it's the worst project I have ever seen from just about every perspective.)

If a common/basic library has an issue, then it typically affect you no matter what language you use to access it. Interpretation and/or code generation bugs can also affect just about anything you can think of, so there's no way out of that either. I think you should choose a platform with a good track record and a sane and security-aware design as opposed to something with a horrible track record and no security awareness what-so-ever. You won't be "safe", but you'll be better off.

I think we can all agree that "forget about even trying to write safe code, someone else has probably made a misstake anyway" is a very poor philosophy.

forget about even trying to write safe code, someone else has probably made a misstake anyway" is a very poor philosophy.


I agree with this. I want to extend it to say that "even with the best platform choice and most careful developers, there will be problems, and the only sane security posture is to be ever vigilant, be on the look-out for issues, and fix them as soon as you find them."
enum Bool { True, False, FileNotFound };
Advertisement

Platforms like .NET are designed in such a way that many problems cannot happen in the first place, while many others can be caught and handled in safe and secure ways. I wouldn't be the slightest surprised if we saw a production quality derivate of Singularity (OS by Microsoft written in C#) for servers sometime soon for this very reason. It has so much better potential to be secure.

In C# .NET asp, it is not possible to reference CLR/c++ custom libraries, if you tend to provide untrusted hosts. But I would fluently bet that even in the pile of C# namespaces one could too find an illegal exception invoking usage in native runtime and hang the server. I do not know how much Java is problematic on this, but hey, you have no untrusted hosts- no problem anymore.

i wanted to make a different topic for my question but my next question is similar to the topic.

for data that is send and received in network, is this usefull to use RSA to encrypte data. you think its a very slow process to work or its just fine? you said never send a fake data like my position is something else than reall one and use data like button pushed or... but my game is realltime but its a mmo that needs to be not manipulated. so ia have to encrypt my data. you think is RSA gonna work well or in your exprience is not good for a game?

You shouldn't use rsa for stream encryption.

Well tested libraries like ssl use rsa for key exchange and then aes, blowfish, etc for the stream or block cipher with that key.

In short never try and write your own encryption, use something tried and tested like an ssl library.

Keep in mind that data-stream layer encryption is not going to even remotely begin to stop cheating/packet forging.

Attackers will simply modify the data they want to manipulate, in-memory, before it reaches the encryption function. This is trivial to accomplish in most cases.

You must server-validate input. Relying on encryption to protect you from fake data is a mistake.

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]

Advertisement


You must server-validate input. Relying on encryption to protect you from fake data is a mistake.

wow. what you mean? there is not much data in the client that a hacker wants to hack that. in most part of the game i just send players input to server. nothing more. but in some parts there should be sent some data like player authentication data like name username mail and password. maybe a hacker can read those data from memory. but how can i fix that. every packet just contains json format of request string to server, player data input string and some authentication data like i said. i encrypt result data with RSA and make that string to binary and send that. in server something like this will be happened.

but how can i fix the matter you said?

Encrypting traffic can make it more difficult to sniff/intercept the communication and stealing other peoples account data and it can potentially also prevent varous forms of cheating such as knowing stuff only the server and that particular client should know. It does not prevent a hacker from sending anything he wants from his own computer, but it can prevent him from impersonating another client.

So yeah, encryption is awesome and can bring alot of benefits, especially for the non-hacking players, but it does not mean you can trust whatever is received just because it was received over an encrypted channel.


So yeah, encryption is awesome and can bring alot of benefits, especially for the non-hacking players, but it does not mean you can trust whatever is received just because it was received over an encrypted channel.

there is some information checkings on server. for example when data decodes in server it checks some parts and some prameters of f json result file. but can you tell me about those checkings and how to fix the problem.

next thing is: is encryption and decryption a havy process? using RSA adds much process to server or or clients or not?


In short never try and write your own encryption, use something tried and tested like an ssl library.

i think ssl is specially for web. maybe its possible to work with it in sockets. im not writing my on encryption. im using using System.Security.Cryptography; what can be problem of working this way? my just probable problem i think is RSA may be heavy process for encrypt and decrypting strings

This topic is closed to new replies.

Advertisement