Tag Info

New answers tagged

0

I think we should keep things in perspective here. Is visiting a news site over HTTP non-secure or a security issue? Visiting a site over HTTP is fine as long as sensitive information is not transmitted over HTTP. Is visiting this site over HTTP an issue? It might be! If you are authenticated (logged in), the session cookie is transmitted in each request. ...


1

Yes, it's unsecure. You send your requests and all data in plain text. I am not sure about cookies, but other data is not safe. If somebody make a MITM (Man In The Middle) to you, he can see what you send and what you receive. Also and your ISP ( Internet Service Provider) can see your data which you send to some http web site.


3

You should always set the cookie as HTTPOnly if your cookie contains sensitive information (such as personal info, session related info, session identifier etc.). This prevents JavaScript from accessing this cookie in case of an XSS bug in your website. As far as Secure flag is concerned, you should set your SECURE cookie attribute if your clients ...


3

Just let them buy a new one. You may be thinking of a process like in DNS ownership transfer. But there is no such thing for certificates. Anyone who can answer an email for admin@example.com will get a certificate for example.com. It's as simple as that.


4

According to RFC 6265 section 5.2, the individual attributes of the Set-Cookie header are processed in whatever order they're found, and the Secure and HttpOnly attributes are simply used to set discrete values with no reference or relation between the two: If the cookie-attribute-list contains an attribute with an attribute-name of "Secure", ...


3

Pragma is deprecated in favor of Cache-Control, but because of its common misuse as a response header there are clients and proxies who will interpret it as such. Past squid versions are an example and starting with 3.2, Squid is advertising and attempting to fully support HTTP/1.1 specifications meaning pragma in a server response has no meaning whatsoever ...


3

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


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


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


0

In addition to what some of the answerers pointed out, most secure sites (e.g. banking web site, etc.), will not even allow you to access secure content through their sites via http. So, using http is not even an option with these sites - you have to use https.


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


0

You can sniff HTTP Packets using Tools like Wireshark and its like a walk in the park to read your data Packets.An attacker can Intercept your Data Packets modify it and forward it. eg:You ask your bank to pay you - Attacker modify this packet and ask the Bank to Pay Him. I dont understand what you mean by HTTP in your WIFI Network.Dont you want to access ...


0

"Secure enough" and "trusted" are risky phrases. If you're talking about transmitting a credit card number, email address, SSN, or other personal information unencrypted as plain text via a URL parameter then this is definitely unsecure, regardless of where it is going. The page would need to be an encrypted page for that information to be encrypted in ...


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.


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


0

Do you think that's possible or are aware of software that's capable of doing this? Or maybe another way to accomplish unrestricted internet access under these cirumstances? If you are in control of a server reachable by the service you mentioned then you could built your own tunnel, because you can send data through the tunnel to the server (via the ...


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


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


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


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


0

Here you go. Ctrl+f and search for "http," and you should find the default port for various programs' http servers, such as "GNUmp3d HTTP music streaming and Web interface" and "WebSphere Application Server HTTP Transport (port 1) default." It's generally not good to post links as the only substantial content in answers, but there are so many default ports ...


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


0

Each connection should be send completely (so send a complete incomplete request), the incomplete GET request will make the server think that you are on a poor connection and keeps waiting for the rest of the request. Each connection does require its own port, for this reason slowloris doesn't work well on windows, which limits it to ~130 ports. Sending the ...


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.


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


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



Top 50 recent answers are included