119
Quite obviously, if they can display your password, then they are storing your password somehow. They might cache your password on the client-side when you log in (for unjustifiable reasons, like session management), but more likely their password database is in clear text. Either way, it's stored and it should not be.
And it looks like they are running a ...
71
It's a complex matter because there are several aspects to consider, with pros and cons, and there might not be a definite answer.
The security advantage of open source software is supposed to come from a "law" that Wikipedia calls "Linus's law", which says that "given enough eyeballs, all bugs are shallow". To start with, you'd have to ask yourself how ...
13
The plaintext password is a gaping security issue.
First, they shouldn't even know it. Passwords should be stored hashed and salted. Anyone who doesn't do that is an [censored by editors].
Second, sending the password over the wire when not strictly necessary is a second huge security mistake.
Third, including it in the webpage at this point only adds ...
10
It's important to read what I wrote in context.
Yes, there are occasionally valid use cases for security through obscurity.
This was written in response to a question about penetration testing a black-box system, where the idea of the source being available wasn't even on the table. In such a case, security by obscurity can have a certain amount of ...
8
Security through obscurity isn't a bad thing, it just isn't a reliable one. It should never be your main or only method of protecting something. It can be misleading and illusory. But it still has some value, on top of other methods. Not knowing your platform might slow down an attacker, or cause him to miss possible avenues of attack. Particularly since the ...
7
To be honest, we don't know.
They could store the password in plaintext, they could store it encrypted. Both would be quite desastrous. They could store it in the session (i.e. server-side) when you log in which would be somewhat less desastrous but still bad. They could even have you store it in a cookie (i.e. client-side) and then have the script showing ...
6
The most likely reason is that a machineKey node is set in the web.config for each of the web applications, and the node has the same values for both. This node contains the key for encrypting and decrypting the authentication cookie, and by default (if the node doesn't exist) the server will create unique keys for each application. If, however, you ...
4
There is an important difference between publishing your code, and failing to protect your code from being accessed by an exploit.
If you publish your code, there will be blackhats, greyhats, and whitehats with access to your code. The whitehats will disclose any vulnerabilities they discover, and greyhats may disclose them if the bug bounty is big enough. ...
4
The only thing to know when coding an application is that you should not trust the client.
This being said, all calculations that you do client-side need to be checked and sanitized by the server. If everything is properly sanitized, then you do not need to block something on the browser.
Furthermore, let's say that you use a Javascript function ...
3
The problems you will face with "mixed content" are many, and well documented. For instance, see Google's own description.
Some simple examples are:
Session cookies may be sent in clear when fetching the image, if it is on the same domain (provided "secure" is not set)
Attackers may substitute the content loaded over HTTP with something malicious that ...
3
First, let's clear up a misconception. There is no such thing as a "server-side cookie." While a server can send cookies with an HTTP response, there is no server-side cache of valid cookies. That is a construct that only exists on the client side in a user agent (such as a browser) that supports it. This is what makes cookies powerful. You can maintain ...
2
updateprofile.php?uid=1 I can change to
updateprofile.php?uid=2
If you can change the uid parameter and then tweak other persons profile that would mean the backend application has no checks as to determine if a user is eligible to perform an action.
This attack can be a combination or any of the following including (bad session management,url ...
2
I have developed several open source projects including Digitalus CMS 2007-2012. Now that we have build tools like NPM I prefer an approach where I share specific, more generic modules, which would be next to impossible to claim intellectual property for, then keep the final implementation private.
This approach is easier to adopt for a wider range of ...
2
ACAO: * will prevent the browser from automatically sending any form of credentials, but that's only relevant for the kinds that the browser can actually send automatically (cookies and HTTP BASIC, DIGEST, and NTLM auth). HTTP auth does use the Authorization header, but not with a Bearer token. Because ACAH: Authorization is specified for both the pre-flight ...
2
Some applications work around this by using ftp. They login to localhost with a given username. That’s more portable on some Webhosters that sudo.
It is a good practice if the web server cannot modify code, because this is a very common way for permanent infection. On the other hand for convenience it’s often done. If your scripts are secure (and you don’t ...
2
Theoretically speaking, the answer is, of course, "It depends." Practically speaking however, for the client side the answer is "probably not" and the answer for the server side is "yes, with caveats."
Client-side:
This is the situation you're describing. You visit a site with your browser, explicitly specifying the HTTPS protocol, and are immediately ...
1
To answer your question: It's really not a good idea to let any less-than-fully-trusted process self-modify, and that's especially true for frequently-launched and highly-exposed programs like web servers. The principle of least privilege applies really strongly here, and web servers do not need the ability to self-modify.
Fortunately, there are solutions. ...
1
1) Is there any way that I as a client can establish if there is a MITM/attacker which is denying/redirecting HTTPS connection? (this cause is suggested by the "HTTPS Everywhere" plugin)
Totally depend on site configuration: the redirect may be set only to frontpage or for all ressources. There's no generic answer to this question.
Nevertheless, since HTTPS ...
1
I believe the following contrived back end would satisfy your requirement:
SELECT * FROM Customers Where '$uid'='SuperUser'
Which becomes
SELECT * FROM Customers Where ''=''OR''='SuperUser'
As for preventing this sort of thing the answer is true for all SQLI. Sanitize and validate all user inputs.
1
You cannot make a static page secure with client side scripting. It's impossible. You have to have some server side component that validates the user credentials.
Remember that the user has full access to modify any code running in their browser, and can manipulate it at will.
You can do your OAuth authentication in Javascript, and hand the acquired Token ...
1
Client-Side is never secure. You have to implement a way for the server to differentiate between authorized and unauthorized users.
For this, you need some server-side logic, which goes more into the realms of programming than information security.
1
Can this be exploited?
Yes, the attack is exactly as you described it. An attacker who could steal a token is valid, even after the user logs out. This is not best practice, although how practical this is is up for debate.
Why does ASP.NET do this?
This is a difficult thing to answer, as we don't know the design mentality behind it. What is clear that it ...
1
Looks like this is a known session replay vulnerability in ASP.NET with several workarounds .
1
Yes it is possible, but only in certain cases. There are two general classes of Header Injection attacks that I am aware of:
One is a Man-in-the-Middle (MITM) attack where someone is intercepting your traffic to inject header info. HTTPS connections protect against these.
The second is a Cross-Site Script (XSS) attack. These are attacks against an ...
1
A possible scenario for Case 4 is one where a MITM replaces an image with
one that exploits an RCE (remote code execution) vulnerability in the user's browser.
Here's an example of such vulnerability: https://nvd.nist.gov/vuln/detail/CVE-2017-2416
--basically you can serve a crafted image containing executable code
and have that code executed on older ...
Only top voted, non community-wiki answers of a minimum length are eligible
