New answers tagged web-application
1
This is making a prepared statement. It won't sanitize the inputs. At a low level, it's probably using the sqlite c api, and it would look something like:
stmnt = sqlite3_prepare("INSERT INTO table (e1, e2) VALUES(?, ?)")
sqlite3_bind_int(stmnt,0,V1)
sqlite3_bind_blob(stmnt,1,V1)
while((row = sqlite3_step(stmnt) != SQLITE_DONE){
//do something ...
2
if a user is on my site's login page, he would have the keys to the secure connection
I don't know what you meant by that...
Client-side protection is more of a help than a protection. If a field on the form must be an email, a client-side email validation will help the user know that the email is invalid before sending the form, and having to probably fill ...
2
Any validation done client-side shouldn't be trusted, because it can easily be ignored, bypassed or broken. It's trivial to post requests to your login form handler without using the actual page hosting the form, so that handler should always validate all input it receives.
1
Cloudflare is essentially a reverse proxy which might also cache content. If the content is then actually served from the cache or if the request is passed through the origin server can be influenced by the server itself through the use of standard Cache-Control HTTP headers. Thus, if the server wants to control access to specific content but still allow ...
0
Eight years later . . . you can try using CNG DPAPI, which was meant to work in cloud environments that may or may not be load-balanced. From that link (in case it gets taken down):
Microsoft introduced the data protection application programming
interface (DPAPI) in Windows 2000. The API consists of two functions,
CryptProtectData and CryptUnprotectData. ...
1
As Tom Leek points out in his excellent answer (which he penned in 2014) - with client-side hashing... 'what the client sends is password equivalent'.
This is why we now have protocols like PAKE and SRP. With PAKE or SRP, the server authenticates the client based on a password known by the client - but without the password (or password-equivalent data) ...
3
A Content-Type header is applicable to a response with a body per RFC 2616:
When an entity-body is included with a message, the data type of that
body is determined via the header fields Content-Type and Content-
Encoding.
By extension, it's not necessary if there is no response body, as you're describing.
It is a SHOULD and not a MUST, so it is RFC-...
0
Perhaps this article in the NetSparker knowledge base might be useful to you.
"[...] a missing Content-Type header which means that this website could be at risk of a MIME-sniffing attacks. [...] The problem arises once a website allows users to upload content which is then published on the web server. If an attacker can carry out XSS (Cross-site ...
1
I believe he is right. It sounds like the parameter that provides the '9' is under control of the user / provided by the query string in the URL that links to this page, right?
Since the parameter is already inside some JavaScript, the attacker would not need to inject angle brackets or quotes to inject JavaScript code and cause a Cross-site Scripting (XSS)....
0
There is actually one small thing you might check to see, if the request comes from the authenticated user, that has little probability to backfire (unlike the IP check) and a bit of chance to actually prevent an attack. Look on the User-Agent header. It is not expected that within the user session the value of the header changes. If it does, then it might ...
1
As @multithr3at3d commented, if the attacker already has local access its game over. There isn't much you can do to protect against session hijacking if an attacker has compromised your user's device. You could try to check the IP of the client when it makes a request to ensure that it is the same IP from which the session was initiated. This isn't a good ...
1
It depends on what you mean by "the best".
From the security point of view, server should not trust any data received from the client and should validate all the data. Why? Because you don't know who and why sent these data. May be user has modified your JavaScript and forced browser to send to the server the data, that you believed your script ...
1
Will security officers (CSO) in companies in general accept this or not for a 3rd party solution installed on prem?
Nobody CSO can tell you how another CSO will answer that question. Personally, as an Active Directory admin I successfully advised against implementing dozens of applications already, that provide LDAP or local authentication already.
At ...
0
"As soon as you're displaying content from another domain, you're basically trusting that domain not to serve-up malware.
There's nothing wrong with iframes per se. If you control the content of the iframe, they're perfectly safe." - Shamelessly stolen from this thread.
However your web app could be vulnerable if there is XSS vulnerability inside ...
2
While the differences between authenticity and integrity are difficult in practice, as your example of a compromised key set illustrates, as far as I understand it, this aims at the network level rather than the logic level. Thus, checking the integrity comes down to trusting the authenticity of the certificate and accepting only such cipher suites that ...
2
In this case should I worry about the XSS possibility? Should I check the inputs and sanitize them for every request?
Yes, you should worry about this foundational piece of security. Even if you can't currently envision an attack vector today, as your software evolves, you are leaving landmines in your wake that you will quickly forget about. It will become ...
2
You can point a domain name to a private IP address. As a random example, the company I work for has a domain name local.example.com that points to 127.0.0.1. Not that the details matter much, but it uses this for providing MFA to command line tools - the local application will launch a browser window with our SSO/2FA provider, and the return URL for the ...
-1
Recently, with the hacking of a lot of databases, there has been a rash of emails going around that claim to have hacked you and been watching you over your webcam and will release embarrassing data if you do not pay them. They will then have some gibberish and a message about knowing your password. Usually, in the gibberish, you will see your password and ...
1
Well, which is it? A user or an attacker? A user doesn't care about the key, an attacker does.
An attacker doesn't really even care about the key, but rather the password. Moreover, an attacker doesn't really even care about the password, but in fact the data in the database.
If an attacker could reasonably get the key out of the user profile (which is what ...
Top 50 recent answers are included
