Tag Info

Hot answers tagged

8

If the input is not carefully filtered, then that is a vulnerability called 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 request, possibly ...


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 ...


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.


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 ...


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 ...


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

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 ...


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 ...


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

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 ...


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 ...


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. ...


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

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 ...


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 ...


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, ...


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 ...


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 ...


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

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 ...



Only top voted, non community-wiki answers of a minimum length are eligible