Tag Info

New answers tagged

0

Any input to the user, whose content may be used in a database query is a possible vector of SQL injection. For example, with your example URL, depending on your server implementation this might work: https://testurl.com:1234/webservicename?parameter=DROP TABLE users;SELECT The key to preventing SQL injection is simple and we'll understood, always use ...


1

SQL injections have nothing to do with whether or not your application accepts URL parameters. They work with any input, be it the URL, the request body, a cookie, an HTTP header or even data from your own application (e. g. a string stored in your database). It doesn't matter. So it's not about the origin of the input. It's what you do with the input. If ...


0

What you might want to have is a passwordless access to the ssh service. This will stop brute force attempts on the ssh service. Of course if your machine is compromised to begin with, then you'll need a larger proverbial boat.


1

The app will keep user credentials (login and password) encrypted in a local database. I'm not sure which encryption scheme to use though. Don't encrypt the password, hash it. Ideally using something like bcrypt. I'm considering either a long duration multi-use token or short duration one-time tokens. The shorter the better, in order to reduce ...



Top 50 recent answers are included