Tag Info

New answers tagged

7

If the input to that website is not carefully filtered, then that is a vulnerability known as Server Side Request Forgery (SSRF). There is even a common weakness enumeration number and page for it. https://cwe.mitre.org/data/definitions/918.html By providing URLs to unexpected hosts or ports, attackers can make it appear that the server is sending the ...


5

Well depending on how they've implemented this feature it could indeed be quite dangerous. In addition to to the risks you've mentioned there's also the potential for non-public URLs to be retrieved by the system. For example retrieving http://127.0.0.1 would retrieve localhost. This can be a risk as things like administration panels are commonly deployed ...


0

CSRF Protection on Logout is a must ! Why? Assume the following scenario: You're on a trading page and prepare a buying order for e.g. 1000 Daimlers on an Exchange XETRA. Until you are preparing the order, somebody, who knows that you are logged on https://anybrokerpage.com/ , sends a phishing link to you. e.g. https://anybrokerpage.com/logout By ...


2

Checksums are there just to inform you that nothing has been damaged during download process. You must know that checksums have nothing to do with security features such as encryption. They are there just to be sure with a certain degree that what you got is what you expected. A more secure and better solution is to check the PGP signature as when you try to ...


2

The WebSocket TLS (WSS) connection is a different connection from the HTTP TLS connection. A WebSocket connection is created sending a HTTP request containing the wish to upgrade the connection to WebSocket and by receiving a HTTP response granting this wish. From then on the WebSocket protocol is spoken inside the upgraded HTTP connection. This means ...


1

I believe your premise is flawed. Alice doesn't log on to bob.com via normal HTTPS means, because Alice sees the invalid certificate error and smartly decides not to enter in her credentials. If Alice chooses to ignore the warning and proceed anyway, then now she has the same problem that she would have on any financial or high security site too. Her ...


3

If you made your content malicious, and you have enticed a user to visit your blog then you have already succeeded with your attack. This is just the same as hosting your own website containing malicious content and enticing a user to visit it. The only advantage may be if your target user is likely to trust a *.blogspot.com domain more than any other ...


0

You might want to look into Vault. Vault is an open source tool that provides centralized secret storage that can be accessed over a REST API. It has various methods of authentication (like auth tokens or certificates) and provides policies that can be used for authorization. Keep in mind that it is a good idea to take a step back and look at your ...


1

Keyloggers in JavaScript... BeEF injection string (a JavaScript string to allow BeEF to "hook" the browser..." Also.... you can redirect them to www.myevilsite.org (we're an organization ya know.. we've incorporated...) and do whatever they want to you SOP or not and return you right back to the google site w/the end user being none-the-wiser. Google can ...


0

First, there is a problem with your assumption: "My Javascript and PHP validation are pretty good". You can't make such a statement, because you don't know of all the places you missed. Also, client-side valiation (i.e., Javascript) is useless, security-wise. An attacker can simply bypass it by sending you the corresponding HTTP request directly. Now for ...


0

Defense in depth principles ask to disallow directory listing: why ? Because at least it will lead the nefarious person to waste his time and efforts in getting some valuable information that would probably push him to go away. For the sake of one of our clients, we actually succeeded to have full control on his website after getting a precious information ...


3

Having directory listing enabled is not a security vulnerability just by itself. When you don't want the users to look at the content of a file, the webserver should simply not allow them to access it. When your security depends on the attacker not knowing the exact URL of a file, your security concept is flawed ("security through obscurity"). As long as the ...


2

What you're looking for sounds like Privileged Access Management - a central database that stores administrative and other non-user credentials and allows authorized users to "check them out" for use. Such systems often will programmatically change the credentials on the target system so as to prevent re-use outside the window for which access was granted. ...


1

"Is the Origin not there? If not, OK. If it is, is it one one I trust (e.g. the same origin)? If so, OK." Although you can use the Origin header to reject a request. If the Origin header is missing, you cannot safely accept it, even for POST requests. As far as I know, an HTML form request doesn't include an Origin header, and neither do imgs, ...


4

From the top of my head : the API server's security, which means you may need to hire a competent sysadmin to take care of it if you aren't experienced with system administration. Whatever security you implement on top of that (API authentication, etc) becomes moot if your server itself is compromised. Keep in mind that every software installed on it is a ...


0

Certain compromised websites could lead to malware installation on your computer by simpling visiting them and without noticing anything suspecious. Other websites can perform the same goal by poping-up annoying windows that whether you click on Ok or Cancel or even click on the close corner X could trigger malware installation. In both cases the scenario is ...


0

A fairly comprehensive resource can be found here and here.


1

Any time you include script from an external domain you are trusting that domain. e.g. if you site is example.com and you have the following code on your home page <script src="//example.edu/tracking_script.js"></script> then example.com is fully trusting example.edu not to do anything malicious inside tracking_script.js. example.edu will have ...


0

Are there any blazing "Oh, don't do that!" security flaws in the setup summarized above? The basic protocol you are proposing is: client identifies themselves, server checks the public key and verifies that they are a valid user, server encrypts a challenge using the public key, client decrypts to get the challenge back and returns it as proof of ...


2

regarding question 1: You can setup most webservers as a reverse proxy(IIS, Apache, Nginx and even NodeJS all work). IIS and Nginx are preferable(but not necessary) as they are faster(just my opinion - this may not always be true). Instructions for setting up IIS as a proxy can be found here Instructions for setting up Nginx as reverse proxy there are ...


2

What you could do is hash the old passwords and make the users choose a new one when they login. You really need to force them to use new passwords though since if there's not a 100% chance that the old database was leaked their financial info could be exposed. If you think that the old system was compromised you'd be better off sending out emails, or ...


1

It depends on context. Which are of basic 5 types: HTML context In the body of an existing HTML tag or at the start and end of the page outside of the tag. <some_html_tag> user_input </some_html_tag> In this context you can enter any kind of valid HTML in the user input and it would immediately be rendered by the browser, its an ...


0

Not for all forms, however if the page contains sensitive information such as credentials, and these credentials are auto completed by the browser without user interaction, and the site contains an XSS vulnerability, then an XSS attack could trivially retrieve the credentials without any user involvement at all. Hackavoid has an excellent write-up, and some ...


0

I would slightly disagree with @pineapplemans answer. If we use their example code with user input: <?php $phpvar = $_GET['f']; ?> <script> var jsvar; jsvar = "<?php echo $phpvar;?>"; </script> Then the payload \";alert('XSS');// would not execute. This is because the attack string isn't located directly inside the PHP code, so ...


2

By looking at this payload alone, without the rest of the code, it's probably hard to understand it. Let's say there is JS and PHP code in a website: <script> var jsvar; jsvar = "<?php echo $phpvar;?>"; </script> What this code does is it simply assigns a user controlled variable from PHP to the JS variable jsvar. If the PHP variable ...


-2

There's a few deadly exploits employed by HTML5 that can't be patched, except by the browser itself. The bad thing about patching things like this is that it eliminates functionality as a whole. Things web devs found useful are now restricted because someone abused it. Flash only needs block "strings" in their patching, allowing useful function to remain. ...


2

If the signature is supposed to assert document ownership or acceptance by the user, then the power to sign should remain in the hands of the user (precisely where his "USB etoken" resides). Since signature algorithms begin by a hash function invocation (the message to sign is hashed, and the rest of the algorithm uses the hash value as input), at least the ...


1

The error you get from the page has nothing directly to do with your SQL injection attempt. The site appears to employ a simple casting to ensure id is numeric, so your query becomes a valid query which returns nothing unless you send in a plain number: $id = (int)$_GET['id']; In other words, not all queries you can mess up from the URL line are ...


-1

The error you see is the result of a failed query. This is most likely due to incorrect data being fed to the query string, it's possible mysql_real_escape_string() is being used to escape SQL characters (that would be used in an attack) which would explain why your injection attempt failed. Though more likely would be your incorrect attack attempt. We would ...


0

I don't see any flaw in the method and I think it can be used to protect against CSRF. There is just one small issue: This method will work just fine as long as the cookie storing the CSRF token is NOT set as HTTPOnly. The problem is with this requirement: Application detects/places token. This implementation is similar to Double Submit Cookies. Double ...


-2

No, it's not. A cookie is sent by browser for every request. If the user or the attacker submits the form, the cookie will be sent with the cookie. If the attacker sends the cookie, the user loses. I would employ a hidden form field with a token that is synchronized once for session: User starts session. There are no token yet. Generate a secure token, ...


2

A more complete answer from http://hueniverse.com/2015/07/08/on-securing-web-session-ids/ Disclaimer: like any security advice from someone who doesn't know the specifics of your own system, this is for educational purposes only. Security is a complex and very specific area and if you are concerned about the security of your system you should hire an expert ...


1

I would prefer session based authentication every time. A cookie is not a good option. As @HexTitan said, I am not a fan of cookie authentication too. It's easy (to a extent) to break its security. Bruteforcing a cookie until it spills some secret is not that hard. On the other hand, you must be sure that your sessions have sufficient entropy. If they ...


4

1) There are no security problems. You only have more private keys, which are secure as long as they are not leaked. 2) With HSTS will be no problem, as long as every subdomain has its own certificate, which is trusted, is not revoked and there is not name mismatch.


0

This sounds a lot like ad-injection software installed by accident. This could be something like a Chrome extension or something bundled along with a download. Google recently did a study on the matter, and they state that they "received more than 100,000 user complaints about them in Chrome since the beginning of 2015", making this a realistic scenario for ...


0

There are several sandboxes built into popular software (antivirus engines, Adobe Reader, Java etc.). What all these programs have in common, is that all their sandboxes was already compromised in the past. It's not enough to write just sandbox, as someone will find the way to escape it. What you need to do, is to write a complete virtual machine ...


2

I am not a big fan of the cookie authentication as you had outlined. Session authentication assigns a random token to the client that has no meaning other than being a pointer to the session information stored on the server. The primary problems being low entropy for token generation. However, cookie authentication tends to have more issues. Because the ...


0

i believe that this failure to connect to the user session can be overcome by including the TCP Socket information as a variable during the creation of the cookie. but, as a cookie is just a key/value pair, it all depends on the specific implementation on the server.



Top 50 recent answers are included