搜尋
首頁後端開發php教程优化NFR之一--MSSQLHelloBufferOverflow_PHP


1.  前言  3
2.  报警信息  3
3.  NFR的检测  4
4.  协议分析  8
5.  漏洞说明  15
6.  漏洞分析  18
7.  小结  20


1.  前言
NFR(Network Flight Recorder)是一个老牌的商业网络IDS产品,最初由Firewall的牛人Marcus J. Ranum创建,是作为一个通用的网络流量分析和记录软件来实现的,为了最大限度地发挥分析工具的灵活性,NFR提供了完善强大的N-Code脚本语言,在很多的评测中表现出色。虽然L0pht为NFR提供过数百个签名库,但是缺乏一个可靠的签名集一直是他的软肋。

使用NFR有一段时间后,发现NFR存在着不少问题。且不说AI对中文的兼容性差而经常退出,也不说NFR版本升级而攻击事件说明却一直用旧版本的说明,单是IDS中最关键的攻击签名库,却让我大跌眼镜。除了升级缓慢以外,甚至还存在不少错误的签名。本系列文章针对其中我发现的部分问题进行分析和阐述,以便各位更好地利用NFR产品,同时也想和各位同仁讨论IDS中攻击签名库的编写。由于知识和时间的限制,错误之处在所难免,还希望得到各位的指教,任何意见或建议请发至:benjurry@xfocus.org

SQL Server是微软为对抗Oracle推出的数据库, 占领的市场份额已经仅次于Oracle,居世界第二,但是其安全性也一直受到用户的置疑。从1996年,Microsoft公司推出的SQL Server 6.5版本到1998年推出的SQL Server 7.0,以及到2000年8月推出了SQL Server 2000,在版本和功能不断升级的情况下,安全问题却没有得到很好地改善,不断发布针对SQL Server的安全公告和补丁。在2003年1月24日,针对SQL Server的“Slammer”蠕虫在Internet上肆虐,导致网络流量激增,严重影响了世界范围内的计算机和网络系统。SQL Server的漏洞引起了各大安全公司和厂商的重视,因此NFR也立即发布了多个针对SQL Server的攻击签名,其中包括了2002年8月7日Immunity公司Dave Aitel发现的Hello Buffer Overflow漏洞。但是在使用过程中,我发现NFR针对该漏洞的报警非常多,于是我对此进行了分析,于是写成了这个文章,以做记录。


2.  报警信息
下面是NFR针对MS SQL Hello Buffer Overflow的报警信息:

Severity:      Attack
Time:        13:54:21 15-Jul-2003
Source File:    packages/mssql/sql2k.nfr
Line:        226
Host:        benjurry-xfocus
Alert ID:      mssql_sql2k:buffered_hello
Source ID:     mssql_sql2k:source_me
Source:       mssql_sql2k:source_me
Source Description: Sqlserver 2k overflow detector
Source PID:     36531
Alert Message:   Saw 8 Mssql HELLO overflows from 192.168
          0.110 in 900 seconds
:          3
Source IP:     192.168.0.110
Destination IP:       --

其中包括了事件的严重等级、时间、NFR Sensor名字、攻击源IP、目的IP和一些其他报警信息。
在实际的使用中,一天产生了几百条这种报警,看来这是个误报,我们可以好好的分析一下了。


3.  NFR的检测
我们首先打开NFR发布的签名库 MSSQL.fp(或者也可以在AI的package中查看) 看一下NFR的针对这个漏洞的攻击签名:


…..

变量定义等…



sqlserv_schema = library_schema:new(1, ["time","ip","int","ip","int", "str"],
  scope());
sqlserv_rec = recorder("bin/list %c", "sqlserv_schema");

HELLO_SIG = "\x12\x01\x00\x34\x00\x00\x00\x00\x00\x00\x15";
MIN_LEN = strlen(HELLO_SIG);


…….

filter hello tcp (client, dport: 1433) {
  declare $Blob inside tcp.connsym;
  if ($Blob == NULL) {
    $Blob = tcp.blob;
  } else {
    $Blob = cat($Blob, tcp.blob);
  }

  if (strlen($Blob)     return;

  if (prefix($Blob, HELLO_SIG)) {
    if (COUNTHELLO[tcp.connsrc]) {
      COUNTHELLO[tcp.connsrc] = COUNTHELLO[tcp.connsrc] + 1;
    } else {
      COUNTHELLO[tcp.connsrc] = 1;
    }
    if (do_alert(hello_overflow_alert, tcp.connsrc)) {
      alert(source_me, hello_overflow_alert, tcp.connsrc,
        tcp.connsport, tcp.conndst, tcp.conndport,
        "--AlertDetails",
        "ALERT_ID", "40-8",
        "ALERT_CONFIDENCE", 60,
        "ALERT_SEVERITY", "medium",
        "ALERT_IMPACT", "unknown",
        "ALERT_EVENT_TYPE", "attack",
        "ALERT_ASSESSMENT", "unknown",
        "IP_ADDR_SRC", tcp.connsrc,
        "PORT_SRC", tcp.connsport,
        "IP_ADDR_DST", tcp.conndst,
        "PORT_DST", tcp.conndport,
        "IP_PROTO_NUM", 6);
    }
    record packet.sec, tcp.conndst, tcp.conndport, tcp.connsrc,
      tcp.connsport, $Blob to sqlserv_rec;
    misc_attacks:rec(packet.sec, scope(),
            "Mssql HELLO overflow!", tcp.connsrc, tcp.conndst);
  }
}

从上面的N-CODE中我们可以看到,NFR在做这个检测的时候步骤如下:

1、定义了一个攻击特征码:
HELLO_SIG = "\x12\x01\x00\x34\x00\x00\x00\x00\x00\x00\x15";
和攻击特征码的长度:
MIN_LEN = strlen(HELLO_SIG);

2、从TCP的载荷数据中取出数据,把这个数据的长度和特征码长度比较,如果这个数据长度小于攻击特征码的长度,那么就不再进行下一步的检测;

3、否则,把这个数据和特征码进行字符串匹配,如果一致则认为是攻击行为,然后进行阻止或者报警。
接下来我们分析一下NFR IDS Record的数据,在AI中选择package->Query->MSSQL->MSSQL Server 200,定好条件,按Table查到数据,随便选取一条,copy出来得到如下内容:

Time:        15-Jul-2003 13:54:21
NFR:        benjurry-xfocus
Destination Address:192.168.0.135
Destination Port:  1433
Source Address:   192.168.0.110
Source Port:    1391
Payload:      
          \x12\x01\x004\x00\x00\x00\x00\x00\x00\x15\x00\x06\x01\x00\x1b\x00
          \x01\x02\x00\x1c\x00\x0c\x03\x00(\x00\x04\xff\x08\x00\x00\xc2\x00
          \x00\x00MSSQLServer\x00x\x03\x00\x00

上面这条记录包含了攻击的时间,报告攻击行为的NIDS sessor名字,目的IP、目的端口、源ip和源端口,而我们关心的是有效载荷Payload,因为它是NIDS用来和攻击签名库比较的数据。但是NFR在这里有几个小问题:

1.  会把payload中的能转换成ASCII字符的16进制数转换成ASCII码;

2.  不能处理Unicode的字符,这个将在以后的分析中可以看到。

在这个例子中为了分析方便,我们把上面的payload中的字符特征码部分转换成16进制数:
\x12\x01\x00\x34\x00\x00\x00\x00\x00\x00\x15\x00\x06\x01\x00\x1b
\x00\x01\x02\x00\x1c\x00\x0c\x03\x00\x28\x00\x04\xff\x08\x00\x00
\xc2\x00\x00\x00MSSQLServer\x00x\x03\x00\x00


NFR抓到数据组包后,发现是SQL Server包,便把里面的内容和SQL Server的攻击库进行比较,很明显,上面所列的数据和攻击库是相符合的,因此一个报警便产生了,但是这真是一个攻击行为吗?我们继续看下面的分析。


4.  协议分析

根据Xfocus的协议分析项目(将会在近期公布项目成果),MS SQL 2000用的是TDS8.0,它的格式如下:
-------------------------------------------------
| TDS包头(8字节) |  TDS负载数据       |
-------------------------------------------------
其中MS SQL SERVER 2000 TDS的包头结构如下:
-------------------------------------------------------------------
| TOKEN | STATUS | LENGTH | SIGNED NUM | PACKET NUM | WINDOW SIZE |
-------------------------------------------------------------------
其中TOKEN字段域1个字节,用来表示TDS操作请求种类。在这个漏洞中是0x12,也就是NFR记录中的有效负载中的第一个字节0x12, 0x12是预登录验证命令请求。其目的是获得当前MS SQL SERVER2000的一些设置值,比如SQL SERVER版本,是否支持加密等信息,作为客户端在构造TDS包的一个依据。SQL Server在接受到该类型的包的时候,将会由SSlibnet.dll中的相应函数做处理,在我的系统SQL Server 2000(没有SP)的情况下,相应函数如下:


.text:42CF6DDD ; Attributes: bp-based frame
.text:42CF6DDD
.text:42CF6DDD         public ConnectionPreLogin
.text:42CF6DDD ConnectionPreLogin proc near
.text:42CF6DDD
.text:42CF6DDD var_4      = dword ptr -4
.text:42CF6DDD arg_0      = dword ptr 8
.text:42CF6DDD arg_4      = dword ptr 0Ch
.text:42CF6DDD arg_8      = dword ptr 10h
.text:42CF6DDD arg_C      = dword ptr 14h
.text:42CF6DDD arg_10     = dword ptr 18h
.text:42CF6DDD
.text:42CF6DDD         push  ebp
.text:42CF6DDE         mov   ebp, esp
.text:42CF6DE0         push  ecx
.text:42CF6DE1         mov   eax, [ebp+arg_0]
.text:42CF6DE4         mov   ecx, [eax+94h]
.text:42CF6DEA         mov   [ebp+var_4], ecx
.text:42CF6DED         cmp   [ebp+var_4], 1
.text:42CF6DF1         jz   short loc_42CF6E01
.text:42CF6DF3         cmp   [ebp+var_4], 1
.text:42CF6DF7         jle   short loc_42CF6E3D
.text:42CF6DF9         cmp   [ebp+var_4], 3
……


STATUS字段域1个字节,当它为0x01的时候表示此包为当前TDS会话中的最后一个TDS包。
LENGTH字段域2个字节,表示TDS包的总长度,包括TDS包头的长度。
SIGNED NUM字段域2个字节,目前保留未用。
PACKET NUM字段域1个字节,表示此TDS包在当前TDS操作请求中的序号
WINDOW SIZE字段域1个字节,目前保留未用。
MS SQL SERVER 0X12 TDS的包主要包格式如下:
------------------------------------------------------
| TDS包头(8字节)| 字段指示头 |    信息      |
------------------------------------------------------
其中字段指示头是一个可以变长的表,表的每一项代表了在一个字段在信息中的偏移地址和长度信息,在SQL2000中主要是4个字段,其对应的字段指示头的结构如下:
{
  BYTE CNETLIBVERNO;
  WORD CNETLIBVEROFFSET;
  WORD CNETLIBVERLEN;
  BYTE CENYFLAGNO;
  WORD CENYFLAGOFFSET;
  WORD CENYFLAGLEN;
  BYTE SINSTNAMENO;
  WORD SINSTNAMEOFFSET;
  WORD SINSTNAMELEN;
  BYTE CTHREADIDNO;
  WORD CTHREADIDOFFSET;
  WORD CTHREADIDLEN;
  BYTE FILEDEND;
}
信息内容的结构如下:
{
  BYTE CNETLIBVER[CNETLIBVERLEN]
  BYTE CENYFLAG[CENYFLAGLEN];
  BYTE SINSTNAME[SINSTNAMELEN]
  DWORD CTHREADID[CTHREADIDLEN];
}
其中:
CNETLIBVERNO字段域
偏移:0
长度:1
含义:客户端使用的网络连接库(NETLIB)的版本号信息的字段编号。
说明:
备注:该值固定为0

CNETLIBVEROFFSET字段域
偏移:1
长度:2
含义:客户端使用的网络连接库(NETLIB)的版本号信息的字段偏移。
说明:字段格式是网络字节顺序
备注:

CNETLIBVERLEN字段域
偏移:3
长度:2
含义:客户端使用的网络连接库(NETLIB)的版本号信息的字段长度。
说明:字段格式是网络字节顺序
备注:该值固定为6

CENYFLAGNO字段域
偏移:5
长度:1
含义:客户端使用强制加密标记字段的字段号。
说明:
备注:该值固定为1

CENYFLAGOFFSET字段域
偏移:6
长度:2
含义:客户端使用强制加密标记字段的偏移。
说明:字段格式是网络字节顺序
备注:

CENYFLAGLEN字段域
偏移:8
长度:2
含义:客户端使用强制加密标记字段的长度。
说明:字段格式是网络字节顺序
备注:该值固定为1

SINSTNAMENO字段域
偏移:0XA
长度:1
含义:客户端要求使用服务器的实例名字段的字段号。
说明:
备注:该值固定为2

SINSTNAMEOFFSET字段域
偏移:0XB
长度:2
含义:客户端要求使用服务器的实例名字段的偏移。
说明:字段格式是网络字节顺序
备注:

SINSTNAMELEN字段域
偏移:0XD
长度:2
含义:客户端要求使用服务器的实例名字段的长度。
说明:字段格式是网络字节顺序
备注:

CTHREADIDNO字段域
偏移:0XF
长度:1
含义:客户端进程的线程ID字段的字段号。
说明:
备注:该值固定为3

CTHREADIDOFFSET字段域
偏移:0X10
长度:2
含义:客户端进程的线程ID字段的的偏移。
说明:字段格式是网络字节顺序
备注:

CTHREADIDLEN字段域
偏移:0X12
长度:2
含义:客户端进程的线程ID字段的长度。
说明:字段格式是网络字节顺序
备注:该值固定为4

FILEDEND字段域
偏移:0X14
长度:1
含义:此字段标记字段指示头已经结实,下面的就是字段的信息。
说明:结束标记是0XFF
备注:

CNETLIBVER字段域
偏移:0X15
长度:6
含义:客户端使用的网络连接库(NETLIB)的版本号。
说明:其版本号取的是DBNETLIB.DLL的版本
备注:其格式是网络字节格式,如版本号为80.528.00,则为
  08 00 02 10 00 00

CENYFLAG字段域
偏移:0X1B
长度:1
含义:客户端强制加密标志。
说明:0代表客户端不强制加密,1代表客户端使用强制加密
备注:

SINSTNAME字段域
偏移:0X1C
长度:SINSTNAMELEN
含义:客户端要求使用的实例名。
说明:单字节格式
备注:默认实例使用MSSQLserver这个名字

CTHREADID字段域
偏移:0X1C+SINSTNAMELEN
长度:4
含义:客户端进程的线程ID。
说明:字段格式是主机字节顺序
备注:

由上面的格式可以看出,一个用默认实例名MSSQLserver连接的SQL TDS包格式将是如下的格式:
\x12\x01\x00\x34\x00\x00\x00\x00
\x00\x00\x15\x00\x06\x01\x00\x1b
\x00\x01\x02\x00\x1c\x00\x0c\x03
\x00\x28\x00\x04\xff\x08\x00\x00
\xc2\x00\x00\x00MSSQ
LServer\x00
\x78\x03\x00\x00

而NFR的攻击签名库却是
HELLO_SIG = "\x12\x01\x00\x34\x00\x00\x00\x00\x00\x00\x15";
明显是正常TDS 0x12预登陆包的一部分,这就难怪会有这么多报警了,那NFR的这个攻击签名是如何得到的呢?
我们还是从它的漏洞说明入手吧!


5.  漏洞说明
下面是NFR N-CODE中对这个漏洞的说明:
FALSE POSITIVES

False positives are unlikely due to the nature of the attack

REFERENCES
Bugtraq Post
  http://cert.uni-stuttgart.de/archive/bugtraq/2002/08/msg00125.html
Exploit
http://www.scan-associates.net/papers/sql2kx2.txt
我们可以看到这个漏洞来自于http://www.immunitysec.com/ 的Dave Aitel,而从http://cert.uni-stuttgart.de/archive/bugtraq/2002/08/msg00125.html所列的MS SQL Server Hello Overflow NASL script中我们可以看到这个漏洞的关键就在于以下几个语句:


pkt_hdr = raw_string(
0x12 ,0x01 ,0x00 ,0x34 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x15 ,0x00 ,0x06 ,0x01 ,0x00 ,0x1b,
0x00 ,0x01 ,0x02 ,0x00 ,0x1c ,0x00 ,0x0c ,0x03 ,0x00 ,0x28 ,0x00 ,0x04 ,0xff ,0x08 ,0x00 ,0x02,
0x10 ,0x00 ,0x00 ,0x00
);

pkt_tail = raw_string (
0x00 ,0x24 ,0x01 ,0x00 ,0x00
);



…..
if(get_port_state(port))
{
  soc = open_sock_tcp(port);

  if(soc)
  {
    
  attack_string=crap(560);
     sql_packet = pkt_hdr+attack_string+pkt_tail;
  send(socket:soc, data:sql_packet);

    r = recv(socket:soc, length:4096);
    close(soc);
  display ("Result:",r,"\n");
    if(!r)
    {
     display("Security Hole in MSSQL\n");
      security_hole(port:port, data:report);
    }
  }

其中pkt_hdr是根据TDS协议构造的包,中间加了560个字符X,pkt_tail是构造的TDS包尾。

从这里我们可以看到,可怜的NFR居然不负责任地把MS SQL Server Hello Overflow NASL script中的pkt_hdr取出11个字符,毅然决然地把它们作为其签名。更为可笑的是居然还写着“False positives are unlikely due to the nature of the attack ”。
这就是在许多评测中遥遥领先的NFR?后来和stardust聊起这个事情的时候,认为这个现象和很多评测机构在评测IDS产品的时候,重视对产品漏报的检测而忽视对误报的评测有关。因为在评测产品时,基本上都是大部分都是黑箱评测,要检测漏报只要收集几个Exploits就可以进行,但要检测漏报却要产生正常的包,有些系统比如这里的Sql Server,如果不了解它的协议包格式,是很难产生的。因此一些IDS产生便钻了这样的空子,只要收集一些Exploits,把其中的攻击代码作为攻击签名直接发布,而不去分析漏洞产生的真正原因。

下面我们来分析一下这个漏洞产生的原因,然后我们就可以根据这个分析,写出比较完善的攻击签名。


6.  漏洞分析
用IDA对SSlibnet.dll反汇编,我们可以看到:


.text:42CF6F49 loc_42CF6F49:     ; CODE XREF: sub_42CF6E4F+EA j
.text:42CF6F49         mov   eax, [ebp+0xc]
.text:42CF6F4C         add   eax, [ebp-0x218]
.text:42CF6F52         push  eax
.text:42CF6F53         lea   ecx, [ebp-0x214]
.text:42CF6F59         push  ecx
.text:42CF6F5A         call  strcpy
.text:42CF6F5F         add   esp, 8
.text:42CF6F62         push  offset unk_42D01104
.text:42CF6F67         lea   edx, [ebp-0x214]
.text:42CF6F6D         push  edx
.text:42CF6F6E         call  strcmp
.text:42CF6F73         add   esp, 8


这个漏洞的原因就在这里,当程序用strcpy拷贝的时候,如果源字符串超出0x214(也就是532)后,目标地址后的环境变量就会被覆盖导致溢出。由于这个漏洞很早,经历了“Slammer”蠕虫后,基本上所有的系统都补掉了这个漏洞,因此这里就不在提供攻击代码了,有兴趣的朋友可以自己分析和编写一下。


另外需要在这里说明的是,如果分析了TDS协议和这个漏洞的成因,完善的攻击程序中的TDS包的长度是根据计算生成的,明显不会是”\x00\x34”,以避过SQL Server中针对TDS包长度的校验(当然在这个版本的SQL Server中还不包含这个校验),或者攻击程序把这攻击代码分成多个包,因此TDS格式中的status就不会是0x01,因此NFR是检测不出完善的攻击程序的的,也就是说针对这个漏洞,NFR 同时存在误报和漏洞的情况。

在分析了这个漏洞的成因后,我们就可以针对这个问题写出自己的NFR检测代码:


sqlserv_schema = library_schema:new(1, ["time","ip","int","ip","int", "str"],
  scope());
sqlserv_rec = recorder("bin/list %c", "sqlserv_schema");

HELLO_SIG = "\x12 ";
#考虑了分包和长度不固定的因素,去除了后面不可靠的特征串
MIN_LEN =29;
#包括TDS包头和字段指示头的总长度

…….

filter hello tcp (client, dport: 1433) {
  declare $Blob inside tcp.connsym;
  if ($Blob == NULL) {
    $Blob = tcp.blob;
  } else {
    $Blob = cat($Blob, tcp.blob);
  }

  if (strlen($Blob)     return;

  if (prefix($Blob, HELLO_SIG) && strlen($Blob) > 295) {
    #考虑到实例名不可能超过255,因此这里长度选择了40(包头)+255=295
#也可以增加一个Value,以便用户自己根据事件情况进行调节
#报警
….

}


7.  小结
通过对NFR这个攻击签名的分析可以看出,发布完善的IDS攻击签名不是一个简单的事情,它需要了解应用的协议格式和漏洞的成因。而不是简单地收集网络上存在地exploits,然后截取其中的特征码。
目前很多人包括IDS开发人月都在讨论IDS有没有前途,需不需要。我想与其在那里讨论,不如静下来好好分析漏洞,完善攻击签名,使IDS做的更准确。
与其坐而论不如起而行!!(出处:www.xfocus.net)
陳述
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
PHP與Python:了解差異PHP與Python:了解差異Apr 11, 2025 am 12:15 AM

PHP和Python各有優勢,選擇應基於項目需求。 1.PHP適合web開發,語法簡單,執行效率高。 2.Python適用於數據科學和機器學習,語法簡潔,庫豐富。

php:死亡還是簡單地適應?php:死亡還是簡單地適應?Apr 11, 2025 am 12:13 AM

PHP不是在消亡,而是在不斷適應和進化。 1)PHP從1994年起經歷多次版本迭代,適應新技術趨勢。 2)目前廣泛應用於電子商務、內容管理系統等領域。 3)PHP8引入JIT編譯器等功能,提升性能和現代化。 4)使用OPcache和遵循PSR-12標準可優化性能和代碼質量。

PHP的未來:改編和創新PHP的未來:改編和創新Apr 11, 2025 am 12:01 AM

PHP的未來將通過適應新技術趨勢和引入創新特性來實現:1)適應云計算、容器化和微服務架構,支持Docker和Kubernetes;2)引入JIT編譯器和枚舉類型,提升性能和數據處理效率;3)持續優化性能和推廣最佳實踐。

您什麼時候使用特質與PHP中的抽像類或接口?您什麼時候使用特質與PHP中的抽像類或接口?Apr 10, 2025 am 09:39 AM

在PHP中,trait適用於需要方法復用但不適合使用繼承的情況。 1)trait允許在類中復用方法,避免多重繼承複雜性。 2)使用trait時需注意方法衝突,可通過insteadof和as關鍵字解決。 3)應避免過度使用trait,保持其單一職責,以優化性能和提高代碼可維護性。

什麼是依賴性注入容器(DIC),為什麼在PHP中使用一個?什麼是依賴性注入容器(DIC),為什麼在PHP中使用一個?Apr 10, 2025 am 09:38 AM

依賴注入容器(DIC)是一種管理和提供對象依賴關係的工具,用於PHP項目中。 DIC的主要好處包括:1.解耦,使組件獨立,代碼易維護和測試;2.靈活性,易替換或修改依賴關係;3.可測試性,方便注入mock對象進行單元測試。

與常規PHP陣列相比,解釋SPL SplfixedArray及其性能特徵。與常規PHP陣列相比,解釋SPL SplfixedArray及其性能特徵。Apr 10, 2025 am 09:37 AM

SplFixedArray在PHP中是一種固定大小的數組,適用於需要高性能和低內存使用量的場景。 1)它在創建時需指定大小,避免動態調整帶來的開銷。 2)基於C語言數組,直接操作內存,訪問速度快。 3)適合大規模數據處理和內存敏感環境,但需謹慎使用,因其大小固定。

PHP如何安全地上載文件?PHP如何安全地上載文件?Apr 10, 2025 am 09:37 AM

PHP通過$\_FILES變量處理文件上傳,確保安全性的方法包括:1.檢查上傳錯誤,2.驗證文件類型和大小,3.防止文件覆蓋,4.移動文件到永久存儲位置。

什麼是無效的合併操作員(??)和無效分配運算符(?? =)?什麼是無效的合併操作員(??)和無效分配運算符(?? =)?Apr 10, 2025 am 09:33 AM

JavaScript中處理空值可以使用NullCoalescingOperator(??)和NullCoalescingAssignmentOperator(??=)。 1.??返回第一個非null或非undefined的操作數。 2.??=將變量賦值為右操作數的值,但前提是該變量為null或undefined。這些操作符簡化了代碼邏輯,提高了可讀性和性能。

See all articles

熱AI工具

Undresser.AI Undress

Undresser.AI Undress

人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover

AI Clothes Remover

用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool

Undress AI Tool

免費脫衣圖片

Clothoff.io

Clothoff.io

AI脫衣器

AI Hentai Generator

AI Hentai Generator

免費產生 AI 無盡。

熱門文章

R.E.P.O.能量晶體解釋及其做什麼(黃色晶體)
3 週前By尊渡假赌尊渡假赌尊渡假赌
R.E.P.O.最佳圖形設置
3 週前By尊渡假赌尊渡假赌尊渡假赌
R.E.P.O.如果您聽不到任何人,如何修復音頻
3 週前By尊渡假赌尊渡假赌尊渡假赌
WWE 2K25:如何解鎖Myrise中的所有內容
3 週前By尊渡假赌尊渡假赌尊渡假赌

熱工具

記事本++7.3.1

記事本++7.3.1

好用且免費的程式碼編輯器

MantisBT

MantisBT

Mantis是一個易於部署的基於Web的缺陷追蹤工具,用於幫助產品缺陷追蹤。它需要PHP、MySQL和一個Web伺服器。請查看我們的演示和託管服務。

ZendStudio 13.5.1 Mac

ZendStudio 13.5.1 Mac

強大的PHP整合開發環境

SublimeText3漢化版

SublimeText3漢化版

中文版,非常好用

Atom編輯器mac版下載

Atom編輯器mac版下載

最受歡迎的的開源編輯器