Tag Info

Hot answers tagged

10

When you type the URL in your browser, the browser will mainly do two things with it: Resolve the host name to get the associated IP address to be contacted, this allow the browser to send the request to the right server, Put the host name which has been actually typed in the Host HTTP header, this allows the server to send an appropriate reply in case ...


4

HTTPOnly disallows the cookie from being read by JavaScript via document.coookie. The Secure flag will restrict the cookie to HTTPS, but if your site has an XSS vulnerability, HTTPS will not protect you. The XSS URL https://example.com?q=<script>alert(document.cookie)</script> works just as well as ...


3

It looks like someone is probing your machine to see if you are vulnerable to the shellshock vulnerability. They are hoping that the command will be executed against the shell and that the response will be returned to them. In this case they are trying to see what system you are running, likely to help choose the next attacks if successful. You should ...


3

This second part of data sent is actually part of a loop on order to artificially keep some activity on the line. If your script was only opening the connection to the server, send the first header, then passively wait, the server would close the connection after some inactivity timeout. Here, you maintain a low activity, actually simulating some kind of ...


3

Since GZBK covered why, I will cover the single simple solution to minimize this and related problems that I and others such as StevenC use. Make your first or default virtual host small fast and light, returning errors on all requests (I have been known to allow a basic css and related resources). This has the advantage of minimizing resource consumption, ...


2

as @GZBK said, this happens because for whatever reason, people are being sent to your server when they try to open those sites. This has happened to many others, and is likely the GFW doing its dirty thing. Here is a nice post about some other guy who had the same thing happen to him. You can use this site to check if the dns is pointed to your server.


2

Users authenticate with their phone number, get a pin text, and if it is correct, they get an access token. Phone numbers are PII, so you should be keeping them safe (encrypted?). Text messages are sent in the clear and are readable by smartphone applications, consider that. Also, are the pin numbers random or can they be deducted easily? Are they valid ...


2

They are doing a man-in-the-middle attack which needs the user to either ignore security warnings or to explicit import the CA used by fiddler. For more discussion about this topic have a look at How can I prevent a man-in-the-middle (MITM) attack on my Android app API?


2

The reason you're getting this is because you load certain resources over HTTP. When you look at the page source code, you'll see this: <link rel='stylesheet' id='google-font-body-css' href='http://fonts.googleapis.com/css?family=Open+Sans+Condensed&#038;ver=4.1.1' type='text/css' media='all' /> <link rel='stylesheet' ...


2

HTTP is an inherently "trusting" protocol: it contains little or no built-in security. This means that it is susceptible to the following: Traffic monitoring Anything transmitted over HTTP can be intercepted and read by anyone connected to any network sitting between the source device and the target server. Traffic redirection and manipulation With little ...


2

I'm glad that you specify that the attacker will not get communication back: many people don't understand that impact of spoofed IPs. Technically, yes, that script is vulnerable to a spoofed IP, but a lot has to happen first: The routers along the network path have to not inspect the source IP for sanity The routers along the network path have to allow ...


1

It's not SSL the mechanism that is "hopelessly broken" but rather SSL v3.0 (and SSL v2.0) the specification versions. After SSL v3.0, the specification was renamed to TLS. TLS 1.0 is still considered secure. I would recommend you use TLS 1.2. And, yeah, as others have said, don't even think about rolling your own. Trying to roll their own by somebody who ...


1

Apart from the technological hurdles of getting a tap on the intercontinental lines that could actually read the data, the scenario you provided is indeed possible. If you use HTTP instead of HTTPS your data is travelling as clear text from end-to-end, so your ISP, anyone inbetween and the ISP of your destination host can read or even modify your data if ...


1

Such a setup can be trusted, since the payment details cannot be extracted by your hacker and the payment details can be verified securely. The thing to watch out for is that a lot of user might not bother to double-check the details on the https page, or if there are 'hidden' paramaters sent along that aren't displayed and verified explicitly.


1

You practically answered your own question, It's completely viable to use a plain response for harden your system against an analysis attempt. Other option could be: Use a random UUID to identify your users publicly and keep the primary key only for internal use. A UUID of 16 characters should be enough to mitigate this type of attack. Finally you should ...


1

It's a case of usability vs "implied" security. By making the requests have the same response code a user has lost the ability to determine if "the website isn't working" due to them typing in the wrong url or the wrong password. As value of the response code itself isn't a necessity for HTTP to work, or even directly related to the url requested. The ...



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