New answers tagged

4

As schroeder has already pointed out, to identify buffer overflow vulnerabilities, you'd need to test the application locally with a debugger. It seems to me that you haven't actually gone through the process of learning to identify and debugging possibly vulnerable applications to buffer overflow. Instead of walking you through the basics of the process ...


0

To find and write exploits for vulnerabilities such as a buffer overflow require privileged access to attach debugger, restart the crashed process, etc. Once the exploit is written, it can often be used reliably against remote targets where you do not have any access. Most bug hunters/exploit writers I know maintain a library of virtual (and or physical) ...


1

Traditional radios work by having electronic circuitry that tunes in only the frequency of interest. The hardware of the radio uses filters and other technologies to modify the signal so that only the desired wave is output. Circuits take care of splitting left and right stereo signals, filtering out side bands, receiving AM or FM, etc.; they ultimately ...


0

It is not a threat (low, medium, high) unless you can exploit it. To determine threat severity you would need to take into account event likelihood and impact. However, it could still be a recommendation to have input validation in place according to OWASP or any other methodology.


0

If you were performing an application review, is this something that might be worth calling out? From a security point-of-view, as you ("anybody could just hit this endpoint directly") and other answers state, this is not something the client can protect against. However, if you're not certain it is already addressed, it may be worth raising with the back-...


0

This is typically classified as client side HTTP parameter pollution, https://portswigger.net/kb/issues/00501400_client-side-http-parameter-pollution-reflected. However it may not be exploitable through an API due to how the browser interacts with the endpoint. It may be possible to leverage the additional parameters for other attacks such as cross site ...


0

No. Client-side validation can be useful for performance or UX reasons, but it is not a security feature and its lack has no security impact whatsoever. Indeed, client-side validation can provide a false sense of security, so purely from a security perspective, I prefer to not see it. Now, if the server is not processing the requests correctly - if adding ...


2

Websockets are not inherently less secure then "normal" web traffic. What you describe as possible attacks against the websocket server can also be used as attacks against your websockets gateway. And while you can check an authentication cookie early in the webserver and abandon the request if necessary you could also check some authentication information ...


1

As said by @stuchl4n3k, HackRF One is a SDR (Software Defined Radio) solution. This mean that the whole "protocol" part is done on software side. The advantages of such a solution is that it isn't limited to one usage: with HackRF One, one may create: GSM / LTE base station. 433 Mhz (garage door) sniffer/emitter. DAB+ (Digital Audio Broadcast) receiver. ...


2

From sniffing POV, HackRF One as well as many other SDRs give you radio wave processing capabilities. This means that you can tune to a wide band of frequencies and capture the signal. What you do with it then is generally beyond the SDR's scope. You can always try to process the signal yourself (e.g. with GnuRadio) and write a decoder the data packets for ...


Top 50 recent answers are included