this is not so much a "how to" question than a concern I have for the security of my website...
This new website I am building is the first attempt at MySQLi, I am slowly picking it up as I go, however I have noticed a few security issues along the way which concern me and as I don't know much about the new system, I was hoping someone may hold the answers.
1 -- I've noticed a new MySQLi database connection ideally must be made on each separate page where a database connection occurs, rather than having a single db.php page and including that at the top of each page with include(db.php);- this doesn't seem to work well with MySQLi. Surely though that exposes your database details including your password to every page available for people to download with programs? Security hole or advantage?
2 -- Also in relation to the question above, with all these new connections being run every few minutes or so when the site is busy, how will your database not be overrun or overload and crash?
Like I said, I'm pretty new to MySQLi so these probably seem pretty obvious to you, but to a learner like me, I am yet to know the answer.
Thanks for any responsible replies.
Aidan.
Surely though that exposes your database details including your
password to every page available for people to download with programs?
Users don't see your PHP source code in their browsers. The PHP is executed on the server, and returns whatever it wants to the browser.
Also in relation to the question above, with all these new connections
being run every few minutes or so when the site is busy, how will your
database not be overrun or overload and crash?
For a busy site it would be more like "hundreds of times per second" as opposed to "every few minutes".
The connection is used only for as long as it takes to read the data from the database into some in-memory structure. This is usually a couple of milliseconds. The connection is then closed or sent back to the connection pool.
Related
Very closely related: How to protect strings without SecureString?
Also closely related: When would I need a SecureString in .NET?
Extremely closely related (OP there is trying to achieve something very similar): C# & WPF - Using SecureString for a client-side HTTP API password
The .NET Framework has class called SecureString. However, even Microsoft no longer recommends its use for new development. According to the first linked Q&A, at least one reason for that is that the string will be in memory in plaintext anyway for at least some amount of time (even if it's a very short amount of time). At least one answer also extended the argument that, if they have access to the server's memory anyway, in practice security's probably shot anyway, so it won't help you. (The second linked Q&A implies that there was even discussion of dropping this from .NET Core entirely).
That being said, Microsoft's documentation on SecureString does not recommend a replacement, and the consensus on the linked Q&A seems to be that that kind of a measure wouldn't be all that useful anyway.
My application, which is an ASP.NET Core application, makes extensive use of API Calls to an external vendor using the HttpClient class. The generally-recommended best practice for HttpClient is to use a single instance rather than creating a new instance for each call.
However, our vendor requires that all API Calls include our API Key as a header with a specific name. I currently store the key securely, retrieve it in Startup.cs, and add it to our HttpClient instance's headers.
Unfortunately, this means that my API Key will be kept in plaintext in memory for the entire lifecycle of the application. I find this especially troubling for a web application on a server; even though the server is maintained by corporate IT, I've always been taught to treat even corporate networks as semi-hostile environments and not to rely purely on corporate firewalls for application security in such cases.
Does Microsoft have a recommended best practice for cases like this? Is this a potential exception to their recommendation against using SecureString? (Exactly how that would work is a separate question). Or is the answer on the other Q&A really correct in saying that I shouldn't be worried about plaintext strings living in memory like this?
Note: Depending on responses to this question, I may post a follow-up question about whether it's even possible to use something like SecureString as part of HttpClient headers. Or would I have to do something tricky like populate the header right before using it and then remove it from memory right afterwards? (That would create an absolute nightmare for concurrent calls though). If people think that I should do something like this, I would be glad to create a new question for that.
You are being WAY too paranoid.
Firstly, if a hacker gets root access to your web server, you have WAY bigger problems than your super-secret web app credentials being stolen. Way, way, way bigger problems. Once the hackers are on your side of the airtight hatchway, it is game over.
Secondly, once your infosec team detects the intrusion (if they don't, again, you've got WAY bigger problems) they're going to tell you and the first thing you're going to do is change every key and password you know of.
Thirdly, if a hacker does get root access to your webserver, their first thought isn't going to be "let's take a memory dump for later analysis". A dumpfile is rather large (will take time to transfer over the wire, and the network traffic might well be noticed) and (at least on Windows) hangs the process until it's complete (so you'd notice your web app was unresponsive) - both of which are likely to raise some red flags.
No, hackers are there to grab as much valuable information in the least amount of time, because they know their access could be discovered at any second. So they're going to go for the low-hanging fruit first - usernames and passwords. Then they'll move on to trying to find out what's connected to that server, and since your DB credentials are likely in a config file on that server, they will almost certainly switch their attentions to that far more interesting target.
So all things considered, your API key is pretty darn unlikely to be compromised - and even if it is, it won't be because of something you did or didn't do. There are far more productive ways of focusing your time than trying to secure something that already is (or should be) incredibly secure. And, at the end of the day, no matter how many layers of security you put in place... that API or SSL key is going to be raw, in memory, at some stage.
I've just started trying to use NodeJS and socket.io to create a simple multiplayer online game (similar idea to online chess). I apologise if the answer to my question is really obvious because I have tried googling around, but I think I am missing some key bit of understanding.
Basically, I need to store a few things on the server while the application is running. For example:
I need to store which socket connections are hosts, and which are players.
I need to store the current state of each game (e.g. in the case of chess, where the pieces are and whose turn it is)
It would also be nice to be able to store all the socket.io "rooms".
Feel free to answer the question at this point, information below is for extra reference.
There are a few things that I have tried or seen online:
When I google something with "persistence", I get results based on saving to a database or something, I don't think this is what I want.
I have tried just adding variables at the top of the NodeJS file, like I would with global variables in an ordinary JS file. This seems to work, but just feels wrong to me, if someone could explain how this works it would be great.
I have also seen things called session variables, I think this might be what I want.
I have seen applications that do this by just passing the information back and forward between to client and server, but I would prefer that the client couldn't just edit the information to "hack" to game.
Any help or explanation appreciated.
Nothing wrong with saving to a database. If your server crashes and restarts a few seconds later, you don't really want everyone's data to just be obliterated. I think you're thinking about it in the way that databases are always long-term and slow. But really, there are DB technologies great for this type of thing, and oft used with socket.io.
The one I'd probably opt for is Redis, which is super fast and stores data in-memory. This means that it's not constantly writing to disk, and it's a bit of a halfway house between having full persistent storage like with MySQL, and the slightly dodgy method of just keeping it in Node memory via variables.
When reddit created "Place", that massive multiplayer drawing with a tonne of concurrent users, they used Redis and Cassandra together. You can read a bit about it here.
I've built an application with node and socket.io to keep track when a visitor visits a page, and leaves. When the visitor leaves I store the time the visitor was on the page to redis. That's all the application has to do.
Here's the thing, the application needs to support ~15k concurrent connections, but I'm getting a lot of handshake errors when the benchmark hits around 10.000 conc. visitors. I don't know why exactly. Does anyone have any experience with these kind of problems?
I also tried scaling the application in multiple processes, using the RedisStore backend for node but haven't had much success.
There are a number of things which could be causing this. You should check your system error logs and see if there are any errors there which may indicate where the problem actually is.
This question has some good information and the limit they were hitting is close to what you are hitting as well. It's worth a look.
https://serverfault.com/questions/10852/what-limits-the-maximum-number-of-connections-on-a-linux-server
I am developing an app that uses long-polling for instant notifications about changes made to base.
App structure is as follows:
there is a questions base and admins are answering them in real time. I have a actions table where actions are stored with timestamps. So every admins browser is polling method that queries database for those actions and if there appears a new action from last check it issues a question update with ajax.
I came to 2 questions i cant find an answer to so i came here.
I have multiple clients that are polling one database. With help of long-polling technique i was able to reduce the latency of process but the server load is still same since its asking database for changes every 2 seconds. Is there a way to reduce amount of database queries somehow because at the moment it seems wrong that lets say 10 clients are asking essentially same information each every 2 seconds. maybe there is technique to reduce server load.
Whether there is a solution to first question or not either way i need to somehow calculate server needs for this kind of app as i might need to increase amount of administrators using it. How could i do that.
I'm mostly looking for setup advise and pointers on how to go about going about this. I'll explain in as much detail as I can think and also note possible approaches that may be plausible.
The aim of this is to create a real time browser game, the best method that I have found for my needs would to use "long polling" with ajax, which will basically setup a request with the server that will "hang there" til the server has something to send it, then re-establish the connection upon receipt for more data. For my purposes this will handle a chat system aswell as character movement, IE: if a player enters the same area the clients there will recieve a response to inform them and thus update the browser client to show this.
The above is relatively easy to implement and I have already made a test-case for it, however I want to improve on it, on the server side it runs a loop for X amount of time before it'll auto timeout and send back and empty string, so another connection can be made, this is to prevent infinite loops and use up resources in cases where it shouldn't. Instead of looking up the database on each loop cycle (would be expensive I believe) for messages that need sending to the client, I use flatfiles, if a file has a modified timestamp greater than the last message sent to the client, then there is something new to send. However I believe this would also be expensive (not as much as using a mysql database though?) when done a couple of times per second.
My thought process on this was to have a C++ program (for speed) constantly running, and use that for very fast lookups in memory for new messages and so fourth, this would also give me the added bonus of being able to have bots within the game that the server can control for a more real-time feel/approach, however I have no clue if this is even possible and my searches on google have been fruitless.
The approach I would most love to be able to do, is to continue to use PHP to do the rendering and control of the page etc, and have the ajax requests go to the C++ application (that will always be running) that can handle all the real-time aspects.
CGI defeats the purpose of the above approach, as it creates a new instance of the application on each request, which is both slow and exactly what I do not want, I have php for that and don't want to switch one perfectally running language for another that would be better suited, PHP however (to my knowledge) can't store things in memory (ram) and so fourth.
Another approach that I have thought about was to use php sockets to connect into the C++ application, though I have no idea how feasible this may be. The C++ application only basically will need to control bots (AI) and the chat system messages.. I have absolutely no idea how to go about handling bots via PHP.
I hope this fully explains what my intentions and goals are, so if anyone has any pointers or advise then please reply and help me out, it would be very much appreciated. If you need any extra information (for if I didn't cover something or something very well) then I'll be happy to attempt to better explain.
How fast do the reactions need to be? For anything approaching real-time action games, AJAX/Comet is going to be much too slow. The overhead is also really depressing.
The way forward for that kind of thing will probably be WebSocket, with a custom server on the backend. But I don't think that means you need to resort to C[++] for this; the bottleneck is most likely going to be the network and not server processor power.
I'm using a Python SocketServer with a trivial message replication system — all the game logic in my case is on the client-side, with some complicated JavaScript maintaining a consistent game world in the face of lag — but even for a more complex server-side I think a scripting language will probably be just fine.
WebSocket isn't ready yet; there are no mainstream browser implementations. In the meantime I'm using a Flash Socket backup that emulates the WebSocket interface. Flash Sockets have their own problems in that they fail to negotiate proxies, but they are fast and hopefully the need for them will diminish as WebSocket arrives properly.
Reading your post sets alarm bells ringing.
How familiar are you with multi-threaded code? With C++? If the answer is "not very", then I fear you might be biting off a quite a large chunk. Why not take advantage of some existing (tried and tested) COMET server implementations rather than this barebones approach? Whatever application you have in mind, it should be quite separate from the comms implementation.
As someone who has implemented a such a server, I can tell you that it will take many design iterations and a helluva long time to get right. Testing such a product realisticly is also a very tricky process.