Files
sqlmap/lib/utils
Raju Ranjan 5e2a6aeec8 fix(search): parse current Bing result links (#6150)
While looking into #6009 I noticed the Bing fallback in -g never
returns anything, even when Bing itself serves a normal results page.

Two things changed on Bing's side. The result anchor now carries
target="_blank" before href, so '<h2><a href="..." h=' no longer
matches at all. And the href is no longer the target URL but a
tracking redirect (https://www.bing.com/ck/a?...&u=a1<base64url>),
where the real link sits base64url-encoded after the "a1" prefix
in the u parameter.

The regex now allows extra attributes on both tags and captures
either the u payload of a ck/a redirect or a plain href. The payload
is decoded with decodeBase64(), which already deals with the
URL-safe alphabet and the missing padding. Plain hrefs still work
the same as before (with &amp; unescaped), in case Bing serves the
old markup to some clients.

Checked against a saved live results page (0 -> 10 links) and the
old markup, and --smoke-test passes. Google still can't be scraped
since it only serves a JS page now, so this doesn't fully close
#6009, but Bing is usable again as a fallback when DuckDuckGo blocks
the IP.
2026-10-21 10:41:33 +02:00
..
2026-01-01 19:12:07 +01:00
2026-10-17 13:06:38 +02:00
2026-07-09 09:56:51 +02:00
2026-07-28 16:42:37 +02:00
2026-07-25 19:10:58 +02:00
2026-07-12 10:32:57 +02:00
2026-07-11 15:51:04 +02:00
2026-07-17 14:46:52 +02:00
2026-01-01 19:12:07 +01:00
2026-07-19 16:31:08 +02:00
2026-08-04 17:02:57 +02:00
2026-10-11 21:20:29 +02:00
2026-08-16 23:52:22 +02:00
2026-08-08 01:07:07 +02:00
2026-07-24 14:27:05 +02:00
2026-07-02 00:19:31 +02:00
2026-07-09 13:25:50 +02:00
2026-08-07 17:04:32 +02:00
2026-06-14 17:05:32 +02:00
2026-07-28 21:58:51 +02:00
2019-05-09 15:47:23 +02:00
2026-07-19 14:46:23 +02:00
2026-07-12 20:27:37 +02:00
2026-01-01 19:12:07 +01:00
2026-06-24 11:11:03 +02:00
2026-01-01 19:12:07 +01:00
2026-06-28 02:09:50 +02:00