New answers tagged

3

Yes, this should apply to all subdomains (see Steffen Ullrich's comment for caveat). In foo.bar.foobar, foo is a subdomain of bar.foobar, and bar is a subdomain of foobar, so therefore foo.bar.foobar is an indirect subdomain of foobar.


0

AFAIK setting the exception in each users browser is the only way to get rid of that message when using a self-signed certificate. But: If your company has a wildcard certificate you could define a sub domain, that is just accessible in local net. If your company doesn't have the wildcard certificate, you could still create the sub-domain, acquire a free ...


1

It is not possible A spoofed http packet would have to travel over a TCP connection. TCP has a 3-way handshake that would prevent communication from a spoofed IP address from ever reaching the server's PHP code. Before application data starts getting sent, here is what would happen: YOU send TCP SYN with spoofed IP SERVER responds with SYN-ACK to that ...


2

Is it possible to send HTTP packet via spoofed IP? No you can't. HTTP is a protocol on top of TCP and doing IP spoofing with TCP is nearly impossible due to the internals of the protocol. You would not only need to send a single spoofed packet like in UDP but you would actually need to reply the packets of the peer with the matching sequence numbers ...


1

Spoiler: you can't. Smart pants: If you can fit the request in a single TCP packet, you can. Or if you control the routing to the spoofed IP. Or the machine with the IP that is spoofed. But: you probably won't be able to do that. The problem is: while HTTP is stateless, it uses TCP, which isn't. Especially, before any actual data is sent, a handshake is ...


0

Here are some reasons that sites do not implement forward secrecy (also called Perfect Forward Secrecy or PFS). By definition, only the TLS-terminating server and the client can decrypt the actual payload. This means that other processes, which may have a legitimate reason to decrypt the cipher text, are locked out of the conversation. There are many ...


4

Yes, the VPN provider is able to see your data. If the data are not encrypted (i.e. HTTPS) the provider will be able to get to the clear text and will also be able to manipulate the data. The usual protections of HTTPS apply, i.e. the provider will see which site you visit but not the clear text data itself because they are encrypted. The provider will also ...


0

I'd rather try to send multiple requests simultaneously. In the vulnerable code, it takes 10 seconds from the check (if you have enough money) till the paying process finishes. Another request arriving just in this timespan might enjoy "free shopping".


0

In Chrome, you can simply press the ESC button to close/abort the connection. Look at the PHP code and you'll see when exactly you should press the ESC button.


4

If you insist on talking HTTP through telnet, a proper HTTP server won't answer you before you're sent two consecutive line feeds, effectively ending your request: GET / HTTP/1.0 <empty line> If the service starts answering you before sending the empty line, it's not speaking proper HTTP, and may be something else entirely. I'd suggest using a tool ...


0

To play MITM with HTTPS, your ISP would need to create fake server certificates on the fly for the domains you visit. Your browser would flag these certificates as security probems, since they would not be signed by any trusted CA. That is, unless you imported the CA certificate used by the ISP as a trusted CA. In that case your browser will think everything ...


5

Effectively they can see everything you do that's not encrypted or sent through a tunnel and in many cases they can see what type of traffic that is too via DNS. I'll list a few examples: What sites you frequent. When you're active on-line. What operating systems you use and in many cases what software you use. How often you patch your computer. The ...


0

Possibly. Not really with new browsers, as they have better security. However a video cannot cause any damage, unless it forced you to have a full hard disk. However pages can. Mostly if you have plug-ins. Scripts can cause malware, and much more.


33

but the implication in the other question is that videos in question have been downloaded and played by media software on the target computer. No it is not. The implication is that there need to be a bug in the code handling the data. For instance the ffmpeg library is used in browsers like Chrome or Firefox and it had several serious bugs in the ...


11

A web browsers video system is just another video player, so the same problems apply which were mentioned in the linked question. The smaller set of supported video codecs greatly reduces the attack surface, but doesn't make bugs in the decoders for these formats inconceivable. The Adobe Flash plugin is renowned for its plethora of security bugs in the past ...



Top 50 recent answers are included